 $ type sys$help:RDBVMS023.RELEASE_NOTES








             VAX Rdb/VMS Release Notes



             (Online Version)
|  
|  
|  
|  
|  
|            -----------------------------------------------
|  
|            November 1987
|  
|  
|  
|  
|            This document contains the online release notes for VAX
|            Rdb/VMS V2.3.  It presents information found in the
|            Rdb/VMS V2.2 release notes, plus new documentation that
|            is specific to Rdb/VMS V2.3.  A summary of the new V2.3
|            features is included in this manual.











|            OPERATING SYSTEM:         VMS
|                                      MicroVMS
|  
|            SOFTWARE VERSION          VAX Rdb/VMS V2.3
|  
|  
|  
|  
|  
|        digital equipment corporation, maynard, massachusetts






   The information in this document is subject to change without
   notice and should not be construed as a commitment by Digital
   Equipment Corporation.  Digital Equipment Corporation assumes no
   responsibility for any errors that may appear in this document.

   The software described in this document is furnished under a
   license and may be used or copied only in accordance with the
   terms of such license.

   No responsibility is assumed for the use or reliability of
   software on equipment that is not supplied by DIGITAL or its
   affiliated companies.


   Copyright (c) 1984, 1985, 1986, 1987 by Digital Equipment
   Corporation.  All Rights Reserved.

   The following are trademarks of Digital Equipment Corporation:


   ACMS           PDP            VAX
   CDD            RALLY          VAXcluster
   DATATRIEVE     Rdb/ELN        VAXinfo
   DEC            Rdb/VMS        VAX Information Architecture
   DECnet         ReGIS          VIDA
   DECUS          TDMS           VMS
   MicroVAX       TEAMDATA       VT
   MicroVMS       UNIBUS         



   (r) Ada is a registered trademark of the U.S.  Government, Ada
   Joint Program Office.









                                      CONTENTS

                   How to Use This Manual . . . . . . . . . . . . . .  ix


   CHAPTER 1       SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES

           1.1     Conversion Considerations  . . . . . . . . . . . . 1-1
           1.1.1     Pre-V2.3 Databases Incompatible with This 
                     Software . . . . . . . . . . . . . . . . . . . . 1-2
           1.1.2     Reprocessing V2.0 Programs After Installing V2.3 1-2
           1.1.3     VARYING STRING Fields Used in Any Index  . . . . 1-3
           1.2     Summary of V2.3 Features . . . . . . . . . . . . . 1-3


   CHAPTER 2       SOFTWARE ERRORS FIXED

           2.1     Software Errors Fixed in Rdb/VMS V2.2  . . . . . . 2-1
           2.1.1     Database Administration and Maintenance  . . . . 2-1
           2.1.1.1     CDD Locking Contention Reduced . . . . . . . . 2-1
           2.1.1.2     The RDMS$BIND_WORK_FILE Logical  . . . . . . . 2-2
           2.1.2     Failure of RESTORE with COMPUTED BY Fields . . . 2-2
           2.1.3     Monitor Processes  . . . . . . . . . . . . . . . 2-2
           2.1.4     RDO Statements . . . . . . . . . . . . . . . . . 2-2
           2.1.4.1     EDIT Statement in RDO and EVE Editor . . . . . 2-3
           2.1.4.2     PRINT Arithmetic Expressions in RDO  . . . . . 2-3
           2.1.5     Data Manipulation  . . . . . . . . . . . . . . . 2-4
           2.1.5.1     Immediately Erased Records and COMMIT 
                       Constraint Lists . . . . . . . . . . . . . . . 2-4
           2.1.5.2     Using a Quoted Period in a Query . . . . . . . 2-5
           2.1.6     Programming  . . . . . . . . . . . . . . . . . . 2-5
           2.1.6.1     Corrected Error Message for RDBPRE and /OBJECT 2-5
           2.1.6.2     Wrapping Long Comment Lines in RDBPRE  . . . . 2-5
           2.1.6.3     VAX BASIC DML and START_SEG_STRINGS  . . . . . 2-6
           2.1.6.4     Error Message Added to Catch Unsupported 
                       String Expressions . . . . . . . . . . . . . . 2-6
           2.1.7     Data Definition  . . . . . . . . . . . . . . . . 2-7
           2.1.7.1     Long Field Names Used with Views . . . . . . . 2-7
           2.1.7.2     Field Level Descriptions in Views  . . . . . . 2-7
           2.1.7.3     Multisegmented Index Retrieval with Numeric 
                       Fields . . . . . . . . . . . . . . . . . . . . 2-7
           2.2     Software Errors Fixed in Rdb/VMS V2.3  . . . . . . 2-7


                                    iii















           2.2.1     DESCRIPTION IS Clause  . . . . . . . . . . . . . 2-7
           2.2.2     CHANGE FIELD or CHANGE RELATION Statements   . . 2-8
           2.2.3     NOT ANY Clause and Missing Values  . . . . . . . 2-8
           2.2.4     The FIRST Clause Used with Statistical 
                     Expressions  . . . . . . . . . . . . . . . . . . 2-9
           2.2.5     Host Variables and Statistical Functions with 
                     RDBPRE   . . . . . . . . . . . . . . . . . . . . 2-9
           2.2.6     Issuing the FINISH Statement with a Database 
                     Handle . . . . . . . . . . . . . . . . . . . .  2-10
           2.2.7     Records Returned with the BETWEEN Clause and 
                     the WITH Clause  . . . . . . . . . . . . . . .  2-10
           2.2.8     The ERASE Statement and Constraint Violations   2-11
           2.2.9     Copying Varying Strings from One Relation to 
                     Another Using RDBPRE or RDO  . . . . . . . . .  2-11
           2.2.10    Success Status Incorrectly Returned on 
                     START_TRANSACTION Failures . . . . . . . . . .  2-12
           2.2.11    Accessing Multiple Databases in Callable RDO .  2-12
           2.2.12    Leading Numerics in File Specifications  . . .  2-12
           2.2.13    Instantiation Parameters . . . . . . . . . . .  2-13
           2.2.14    Nested FOR Loops and Incorrect Context Fixed .  2-13
           2.2.15    BATCH_UPDATE No Longer Permits ROLLBACK  . . .  2-14
           2.2.16    CDD Offset Problem Fixed . . . . . . . . . . .  2-14
           2.2.17    Unexpected Error Messages Returned   . . . . .  2-15
           2.2.18    Assigning RDB$MISSING to a Field Using the !VAL 
                     Construct in Callable RDO  . . . . . . . . . .  2-15
           2.2.19    FORTRAN Precompiler and Dimensioned Storage 
                     Areas  . . . . . . . . . . . . . . . . . . . .  2-15
           2.2.20    Rdb/VMS V2.3 Virtual Memory Improvements . . .  2-16
           2.2.21    RDML Software Corrections  . . . . . . . . . .  2-16
           2.2.21.1    Using Field Names as Host Variables in Record 
                       Definitions  . . . . . . . . . . . . . . . .  2-17
           2.2.21.2    Detecting Field Names That Are Not Part of a 
                       Relation . . . . . . . . . . . . . . . . . .  2-17
           2.2.21.3    The ON ERROR Clause in RDML  . . . . . . . .  2-17
           2.2.21.4    VAX C Escape Sequences . . . . . . . . . . .  2-17
           2.2.21.5    Semantics of the STORE Statement with 
                       Segmented Strings  . . . . . . . . . . . . .  2-18
           2.2.21.6    The NOT Boolean Operator . . . . . . . . . .  2-19
           2.2.21.7    The Null Comment Character in RDML/PASCAL  .  2-20
           2.2.21.8    Host Variables and the BETWEEN Conditional 
                       Expression . . . . . . . . . . . . . . . . .  2-20



                                     iv















           2.2.21.9    Number Sign (#) in C Character String 
                       Constants  . . . . . . . . . . . . . . . . .  2-20
           2.2.21.10   CDD Access Using the PATHNAME Option of the 
                       DATABASE Statement   . . . . . . . . . . . .  2-20
           2.2.21.11   Reserving Clause of the START_TRANSACTION 
                       Statement  . . . . . . . . . . . . . . . . .  2-20
           2.2.21.12   Line Length of Generated Code  . . . . . . .  2-21
           2.2.21.13   Transaction Parameter Block  . . . . . . . .  2-21
           2.2.21.14   Date Parameters for Statistical and Boolean 
                       Functions  . . . . . . . . . . . . . . . . .  2-21
           2.2.21.15   Zero Termination of Text Values Returned from 
                       C Functions  . . . . . . . . . . . . . . . .  2-21
           2.2.21.16   RDML/PASCAL Word Data Types  . . . . . . . .  2-21
           2.2.21.17   DEFINE_TYPE Statement  . . . . . . . . . . .  2-22
           2.2.21.18   The RDMLRTL and Multiple Databases and 
                       Transactions . . . . . . . . . . . . . . . .  2-22
           2.2.21.19   EPASCAL Function Parameters  . . . . . . . .  2-22


   CHAPTER 3       KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS 

           3.1     Database Administration and Maintenance  . . . . . 3-1
           3.1.1     Null Field Designation May Be Lost Following 
                     BACKUP/RESTORE Operation . . . . . . . . . . . . 3-1
           3.1.2     Unimplemented Access Rights  . . . . . . . . . . 3-2
           3.1.3     Database Recovery  . . . . . . . . . . . . . . . 3-2
           3.1.4     Backup Utility . . . . . . . . . . . . . . . . . 3-3
           3.1.5     BACKUP and RESTORE Statements  . . . . . . . . . 3-3
           3.1.6     Invalid Transaction Handle Using Multiple 
                     Databases  . . . . . . . . . . . . . . . . . . . 3-3
           3.1.7     Using CHANGE DATABASE to Specify After-Image 
                     Journaling . . . . . . . . . . . . . . . . . . . 3-4
           3.1.8     Using the SPOOL Command with an Empty AIJ File . 3-4
           3.1.9     Limitation of the UNTIL Qualifier of the RECOVER 
                     Statement  . . . . . . . . . . . . . . . . . . . 3-4
           3.1.10    Stopping SPOOL Using CONTINUOUS Option with 
                     CONTROL-Y  . . . . . . . . . . . . . . . . . . . 3-5
           3.1.11    Problem Using VAX TEAMDATA V1.1 and Rdb/VMS 
                     V2.3.  . . . . . . . . . . . . . . . . . . . . . 3-5
           3.2     Data Definition  . . . . . . . . . . . . . . . . . 3-5
           3.2.1     DESCRIPTION IS Clause and SHOW INDEX Statement . 3-5



                                     v















           3.2.2     CHANGE INDEX and DEFINE RELATION DISABLE 
                     COMPRESSION  . . . . . . . . . . . . . . . . . . 3-6
           3.2.3     Do Not Use System Fields in User-Defined 
                     Relations  . . . . . . . . . . . . . . . . . . . 3-7
           3.2.4     CHANGE and DELETE FIELD Statements and Views . . 3-7
           3.2.5     Limitation on the Length of Description Clauses  3-7
           3.2.6     Multiple Clauses in a DEFINE FIELD Statement . . 3-8
           3.2.7     Using COMPUTED BY Fields in a DEFINE VIEW 
                     Statement  . . . . . . . . . . . . . . . . . . . 3-8
           3.2.8     DEFINE DATABASE Statement  . . . . . . . . . . . 3-8
           3.2.9     DELETE DATABASE Statement  . . . . . . . . . . . 3-8
           3.3     Data Manipulation  . . . . . . . . . . . . . . . . 3-9
           3.3.1     Concatenation Operator with a Signed Longword 
                     Field  . . . . . . . . . . . . . . . . . . . . . 3-9
           3.3.2     Using SORTED with FIRST Statement and 
                     Statistical Expressions  . . . . . . . . . . . . 3-9
           3.3.3     Views and Conditional Expressions  . . . . . .  3-10
           3.3.4     Update Rules Violated in RDO and Callable RDO   3-12
           3.3.5     Ambiguous Context Variable Names in FIRST 
                     Clause . . . . . . . . . . . . . . . . . . . .  3-12
           3.3.6     Statistical Expressions with Complex Views . .  3-13
           3.3.7     Maximum Number of Subquery or Relation 
                     References . . . . . . . . . . . . . . . . . .  3-13
           3.3.8     Storing Data in Views  . . . . . . . . . . . .  3-13
           3.3.9     Using ANALYZE with Data Manipulation Statements 3-14
           3.3.10    Using the ERASE Statement with a CROSS Clause   3-14
           3.3.11    Processing Large Expressions . . . . . . . . .  3-15
           3.4     Rdb/VMS Documentation Errors or Omissions  . . .  3-15
           3.4.1     Command Recall in RDO and CTRL/Z . . . . . . .  3-16
           3.4.2     Updating a Relation Already Reserved in Shared 
                     Read Mode  . . . . . . . . . . . . . . . . . .  3-16
           3.4.3     Declaring Host Variables for STARTING WITH, 
                     MATCHING, and CONTAINING in RDBPRE Programs  .  3-16
           3.5     Programming  . . . . . . . . . . . . . . . . . .  3-19
           3.5.1     Do Not Parse Message Text to Retrieve Formatted 
                     FAO Arguments  . . . . . . . . . . . . . . . .  3-19
           3.5.2     FORTRAN Precompiler and Subscripted Record Data 
                     Types  . . . . . . . . . . . . . . . . . . . .  3-20
           3.5.3     Precompiled Programs . . . . . . . . . . . . .  3-20
           3.5.3.1     RDML Restrictions  . . . . . . . . . . . . .  3-20
           3.5.3.1.1     VAX C Host Variables . . . . . . . . . . .  3-20
           3.5.3.1.2     VAX C String Continuation Character  . . .  3-22


                                     vi















           3.5.3.1.3     Handles in Statistical and Boolean 
                         Functions  . . . . . . . . . . . . . . . .  3-22
           3.5.3.1.4     Path Name and the DATABASE Statement . . .  3-22
           3.5.3.1.5     RDML Documentation Errors or Omissions . .  3-23
           3.5.4     RDBPASCAL DATABASE Statement INCLUDES External 
                     Procedures   . . . . . . . . . . . . . . . . .  3-27
           3.5.4.1     G_FLOATING Problem in Precompiled FORTRAN 
                       Programs . . . . . . . . . . . . . . . . . .  3-28
           3.5.4.2     Header Information on Second Line of VAX 
                       BASIC Programs . . . . . . . . . . . . . . .  3-28
           3.5.4.3     Retrieving Segmented Strings in BASIC  . . .  3-28
           3.5.4.4     Problems with Placement of VAX COBOL Line 
                       Terminator . . . . . . . . . . . . . . . . .  3-30
           3.5.4.5     Concatenating Fields in Precompiled Programs  3-30
           3.5.4.6     Using DATE Data Type in Precompiled FORTRAN 
                       and BASIC Programs . . . . . . . . . . . . .  3-30
           3.5.4.7     Precompiling Without a Database  . . . . . .  3-32
           3.5.4.8     Using Database Fields as Array Subscripts  .  3-32
           3.5.4.9     Scaled Operands in VAX BASIC . . . . . . . .  3-33
           3.5.4.10    Comments Within DML Statements in VAX BASIC 
                       Programs . . . . . . . . . . . . . . . . . .  3-34
           3.5.4.11    ON ERROR Clause in Precompiled VAX COBOL 
                       Programs . . . . . . . . . . . . . . . . . .  3-34
           3.5.4.12    Data Manipulation Statements in VAX FORTRAN 
                       Programs . . . . . . . . . . . . . . . . . .  3-35
           3.5.4.13    START_STREAM Statement Within a FOR Loop . .  3-35
           3.5.4.14    Complex Variables in VAX PASCAL  . . . . . .  3-36
           3.5.4.15    VAX PASCAL MIN and MAX Functions . . . . . .  3-37
           3.5.4.16    AVERAGE Statistical Expression in VAX PASCAL 
                       Programs . . . . . . . . . . . . . . . . . .  3-37
           3.5.4.17    DATE Data Type in VAX PASCAL . . . . . . . .  3-38
           3.5.4.18    Preprocessor File Names for Multiple Module 
                       Programs . . . . . . . . . . . . . . . . . .  3-38
           3.5.5     Callable RDO Programs  . . . . . . . . . . . .  3-39
           3.5.5.1     RDB$INTERPRET and Precompiled Modules  . . .  3-39
           3.5.5.2     INVOKE DATABASE EXTERNAL Not Supported . . .  3-39
           3.5.6     Error Messages . . . . . . . . . . . . . . . .  3-39
           3.5.7     Logical Names for Detached Processes Using 
                     Rdb/VMS  . . . . . . . . . . . . . . . . . . .  3-40
           3.5.8     DSRI Restrictions  . . . . . . . . . . . . . .  3-40
           3.5.8.1     Do Not Enable the VMS System Service 
                       SYS$SETSFM . . . . . . . . . . . . . . . . .  3-40


                                    vii















           3.5.8.2     Unsupported Calls  . . . . . . . . . . . . .  3-40
           3.5.8.3     Passing Invalid BLR with RDB$COMPILE_REQUEST  3-41













                                              How to Use This Manual


   VAX Rdb/VMS, often referred to as Rdb/VMS in this manual, is a
   general purpose database management system based on the
   relational data model.
|  
|  This manual summarizes new V2.3 features, describes software
|  errors that have been fixed in this release, and lists current
|  problems and restrictions.  Material added or modified in V2.3 is
|  highlighted by a vertical change bar ( | ) in the left margin.



   Intended Audience

   These release notes are intended for all users of Rdb/VMS, and
   should be read to supplement information contained in other
   manuals in the Rdb/VMS documentation set.

   To get the most out of this manual, you should be familiar with
   VAX Rdb/VMS, data processing procedures, and basic database
   management concepts and terminology.
|  
|  
|  
|  Operating System Information
|  
|  Information about the versions of the operating system and
|  related software that are compatible with this version of Rdb/VMS
|  is included in the Rdb/VMS media kit, in either the Installation
|  Guide or the Before You Install letter.
|  
|  Contact your DIGITAL representative if you have questions about
|  the compatibility of other software products with this version of
|  Rdb/VMS.  You can request the most recent copy of the VAX System
|  Software Order Table/Optional Software Cross Reference Table,
|  SPD 28.98.xx, which will verify which versions of your operating
|  system are compatible with this version of Rdb/VMS.





                                   ix















   Structure

   This manual contains three chapters:

|  Chapter 1      Summarizes the technical changes and new features
|                 of Rdb/VMS V2.3.
|  
|  Chapter 2      Describes the known software errors that were
|                 fixed in V2.3.
|  
|  Chapter 3      Describes problems, restrictions, and workarounds
|                 known to exist in Rdb/VMS as of V2.3.



   Related Manuals

   For more information on VAX Rdb/VMS, see other manuals in this
   documentation set:

   VAX Rdb/VMS Installation Guide

   A complete description of the steps to follow before, during, and
   after the VAX Rdb/VMS installation.

   VAX Rdb/VMS Reference Manual

   A complete description of the statements and syntax of VAX
   Rdb/VMS.

   VAX Rdb/VMS Guide to Programming

   A detailed user's guide on how to write high-level language
   programs that use VAX Rdb/VMS for database access.

   VAX Rdb/VMS Guide to Data Manipulation

   A tutorial on how to use the components of VAX Rdb/VMS to
   retrieve, store, change, and erase data.

   VAX Rdb/VMS Guide to Database Design and Definition



                                   x















   A tutorial that explains how to design a logical database, and
   how to translate that design into a physical database using
   Rdb/VMS data definition statements.

   VAX Rdb/VMS Guide to Database Administration and Maintenance

   A tutorial that explains how to use the database maintenance
   utilities to perform such operations as backup, recovery,
   restoring journals, and analyzing the database.

   RDML Reference Manual

   A reference manual describing the Relational Data Manipulation
   Language (RDML).






























                                   xi















   Conventions

   This section explains the symbols used in this manual:

   < >         Angle brackets enclose user-supplied names.

   .
   .
   .           Vertical ellipsis in an output display means that
               irrelevant information has been omitted.

|   |          A change bar in the left margin indicates material
|              added in Rdb/VMS V2.3.
|  
|  
|  
|  Reference to Products
|  
|  The Rdb/VMS documentation to which this document belongs often
|  refers to products that are part of the VAX Information
|  Architecture by their abbreviated names:
|  
|        o  VAX ACMS software is referred to as ACMS.
|  
|        o  VAX Rdb/VMS software is referred to as Rdb/VMS.
|  
|        o  VAX CDD software is referred to as CDD.
|  
|        o  VAX DATATRIEVE software is referred to as DATATRIEVE.
|  
|        o  VAX DBMS software is referred to as DBMS.
|  
|        o  VAX TDMS software is referred to as TDMS.
|  
|        o  DIGITAL'S VAX to IBM Data Access software product is
|           referred to as VIDA.
|  
|  In addition, VAX C software is referred to as C, and
|  VAXELN PASCAL and VAX PASCAL is referred to as PASCAL.  When the
|  use of an RDML language statement is not the same in both the
|  VAXELN and VMS environments, that language is specified as
|  "VAXELN PASCAL" or "VAX PASCAL."










                                    xii




















                               CHAPTER 1

             SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES



|  This chapter provides a summary of the technical changes and new
|  features in Rdb/VMS V2.3.  It is divided into two main sections:
|  
|       1.  Conversion considerations
|  
|       2.  V2.3 technical changes and new features
|  
|  A vertical change bar ( | ) in the left margin indicates material
|  added in V2.3.
|  
|  
|  
|  1.1  Conversion Considerations
|  
|  This section details the factors you must consider when upgrading
|  to Rdb/VMS V2.3.





















                                    1-1










   SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|  Conversion Considerations


|  1.1.1  Pre-V2.3 Databases Incompatible with This Software
|  
   The internal structure of the .RDB file changed in Rdb/VMS V2.3
   to provide improved performance.  You must prepare for the
   conversion of pre-V2.3 Rdb/VMS databases before installing V2.3
   software.  After the installation, you use the CONVERT or RESTORE
   statement to convert the database file to a format compatible
   with V2.3.

|  The pre-installation and post-installation steps are covered in
|  the VAX Rdb/VMS Installation Guide for V2.3.  Briefly, you
|  perform these tasks:
|  
|       1.  Make sure all existing Rdb/VMS databases are recovered
|           before installing the V2.3 software.  The pre-V2.3
|           run-unit journal (RUJ) files cannot be applied to V2.3
|           Rdb/VMS databases due to internal structure differences.
|  
|       2.  Back up all existing databases using the RDO BACKUP
|           statement and the VMS Backup Utility (BACKUP).
|  
|       3.  Install V2.3 software.
|  
|       4.  Convert existing, pre-V2.3 databases.
|  
|  See the VAX Rdb/VMS Installation Guide for details on the
|  conversion process.  Also see the section on CHANGE INDEX and
|  DEFINE RELATION DISABLE COMPRESSION in Chapter 3 of these release
|  notes.
|  
|                              IMPORTANT
|  
|          Once a database file (.RDB) is converted to a
|          higher version, you cannot use that database file
|          with an earlier version of Rdb/VMS.
|  
|  
|  
|  
|  1.1.2  Reprocessing V2.0 Programs After Installing V2.3
|  
|  If you are converting directly from V2.0 to V2.3, you must
|  reprocess (precompile and compile) all modules that are linked
|  together into an image (that accesses an Rdb/VMS database) when
|  any one module is reprocessed.  That is, reprocessing is not
|  necessary when none of the modules making up the image is
|  reprocessed.  If you reprocess one module (that is part of an
|  image created by linking multiple modules), then all the modules
|  must be reprocessed.


                                    1-2









                            SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|                                               Conversion Considerations


|  For users meeting this criteria, perform this step after the V2.3
|  installation.  This step is necessary due to the correction of a
|  pre-V2.1 restriction on creating shared images.
|  
|  
|  
|  1.1.3  VARYING STRING Fields Used in Any Index
|  
|  The following task is not necessary if you performed these steps
|  using Rdb/VMS V2.2.  Sites moving directly from a pre-V2.2
|  Rdb/VMS environment to V2.3 should read this note.
|  
|  After Rdb/VMS V2.3 is installed, you must delete and redefine any
|  pre-V2.2 index that uses a VARYING STRING field.  This step is
|  required to correct a software error in pre-V2.2 versions of
|  Rdb/VMS.
|  
|  Multisegmented indexes containing VARYING STRING fields were not
|  being built or searched correctly in pre-V2.2 versions of
|  Rdb/VMS.  Whenever the VARYING STRING field was not the last
|  segment of an indexed lookup, a problem could occur causing an
|  incorrect set of records to be retrieved.
|  
|  
|  
|  1.2  Summary of V2.3 Features
|  
|  This section presents a summary of the Rdb/VMS V2.3 new features.
|  Those features are:
|  
|       1.  The Rdb/VMS Management Utility (RMU), a DCL-level tool
|           that:
|  
|            o  Displays information about the characteristics of a
|               specific Rdb/VMS database (for example, whether
|               after-image journaling is enabled)
|  
|            o  Identifies the active users of one or all Rdb/VMS
|               databases on a single system or VAXcluster node
|  
|            o  Displays summary information about all the
|               currently-accessed Rdb/VMS databases on a single
|               system or VAXcluster node
|  
|            o  Returns useful database statistics, thus providing a
|               performance monitoring system
|  
|            o  Starts or stops the Rdb/VMS monitor



                                    1-3









   SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|  Summary of V2.3 Features


|           The VAX Rdb/VMS Reference Manual and the VAX Rdb/VMS
|           Guide to Database Administration and Maintenance provide
|           information on using RMU commands to help manage your
|           Rdb/VMS databases.
|  
|       2.  Deferred snapshot capability, which gives the database
|           administrator (DBA) the ability to limit the unnecessary
|           writing of updated records to the snapshot file (.SNP).
|           See the VAX Rdb/VMS Guide to Database Administration and
|           Maintenance for information on deferred snapshots.
|  
|       3.  An option to set the initial percentage fullness
|           threshold, or fill factor, of an index node.  See the
|           VAX Rdb/VMS Reference Manual and the VAX Rdb/VMS Guide
|           to Database Administration and Maintenance for details.
|  
|       4.  An option to set the size (in bytes) of each index node.
|           This option, and the fill factor setting, allows you to
|           tune the performance and utilization of your databases
|           indexes.  The index structure can be modified so that it
|           better suits the query or updating environment of your
|           database application.  See the VAX Rdb/VMS Reference
|           Manual and the VAX Rdb/VMS Guide to Database
|           Administration and Maintenance for details.
|  
|       5.  An option to enable or disable data compression on a per
|           relation basis.  Depending on the type of transaction
|           (heavy query, heavy retrieval, or a mixture) a
|           particular relation is commonly used, for which data
|           compression may or may not be beneficial.  See the VAX
|           Rdb/VMS Reference Manual and the VAX Rdb/VMS Guide to
|           Database Administration and Maintenance for details.
|  
|       6.  The ability to link RDBPASCAL and RDML programs with the
|           Run-Time Only (RTO) kit of Rdb/VMS in addition to the
|           RDBPRE languages (COBOL, BASIC and FORTRAN).  Prior to
|           Rdb/VMS V2.3, you could only link the RDBPRE languages.
|  
|           This capability allows you to create applications with
|           the DEVELOPMENT kit and then distribute the object
|           (.OBJ) modules for your application to systems with the
|           Run-time Only kit installed.  Previously, you could only
|           distribute executable (.EXE) application images.
|  
|           For information on how to link programs see the VAX
|           Rdb/VMS Guide to Programming.
|  
|       7.  The ability to eliminate a disk I/O bottleneck by
|           placing the snapshot file (.SNP) and the database file


                                    1-4









                            SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|                                                Summary of V2.3 Features


|           (.RDB) on separate disks.  See the VAX Rdb/VMS Guide to
|           Database Administration and Maintenance for details.
|  
|       8.  A new option to the DEFINE DATABASE and RESTORE
|           statements that lets you specify the maximum number of
|           VAXcluster nodes on which Rdb/VMS users can access a
|           shared database.  See the VAX Rdb/VMS Reference Manual
|           and the VAX Rdb/VMS Guide to Database Administration and
|           Maintenance for details.
|  
|       9.  The process of starting the Rdb/VMS monitor has changed.
|           A new DCL command, RMU/MONITOR START, was added to
|           SYS$MANAGER:RMONSTART.COM for V2.3.  Prior to V2.3, the
|           automatic monitor startup code started the Rdb/VMS
|           monitor (assuming the monitor had not been started
|           already) when a user invoked any Rdb/VMS database on the
|           system.
|  
|           The monitor must be started with RMU/MONITOR START or by
|           running RMONSTART.COM at system startup.  See the VAX
|           Rdb/VMS Reference Manual and the VAX Rdb/VMS
|           Installation Guide for details.
|  
|      10.  Command recall in the interactive Relational Data
|           Operator (RDO) utility, that lets you recall up to the
|           last 20 commands entered in your RDO session.  See the
|           VAX Rdb/VMS Guide to Data Manipulation for details.
|  
|      11.  The SEGMENTS options on the RDO ANALYZE statement.  The
|           new option lets you analyze only the segmented string
|           portion of a database.  See the VAX Rdb/VMS Reference
|           Manual and the VAX Rdb/VMS Guide to Database
|           Administration and Maintenance for details.
|  
|      12.  The SHOW FIELDS statement has been enhanced so that the
|           database handle will be displayed in addition to the
|           field names and relation name, whenever a database
|           handle is used to invoke the database(s).
|  
|      13.  A BATCH_UPDATE transaction will not allow a user to
|           issue a ROLLBACK statement.  Instead, an error message
|           is issued and the transaction is not rolled back.  See
|           the VAX Rdb/VMS Reference Manual and the VAX Rdb/VMS
|           Guide to Data Manipulation for details.
|  
|      14.  The RDBVMS$REM account introduced in Rdb/VMS V2.2 is
|           renamed to RDB$REMOTE.  See the VAX Rdb/VMS Installation
|           Guide for details.



                                    1-5









   SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|  Summary of V2.3 Features


|      15.  The DBKEY SCOPE option of the VAX Data Distributor RDO
|           statement DEFINE TRANSFER is no longer available.  The
|           DBKEY SCOPE option of the DEFINE TRANSFER statement was
|           removed from RDO in this release.  The DEFINE TRANSFER
|           Statement does not use the DBKEY SCOPE clause.  No VAX
|           Data Distributor functionality has been lost by the
|           removal of this clause.
|  
|      16.  RDO can be invoked as a foreign DCL command.  See the
|           VAX Rdb/VMS Guide to Database Administration and
|           Maintenance for details.
|  
|      17.  Prior to V2.3, the default for the "maximum" parameter
|           of the multivolume extension clause was 1,000,000 pages.
|           Because this was considered not very useful for a large
|           majority of Rdb/VMS databases, the default maximum value
|           has been lowered to 10,000 pages (as documented).
|  
|      18.  Prior to V2.3, the maximum number of fields allowed in a
|           relation was 1000.  Starting in V2.3 a relation may have
|           a maximum of 2000 fields.
|  
|      19.  The RDO SHOW DATABASE statement displays the full file
|           specification (device, directory, file name and type)
|           for each database invoked by the process that issues the
|           RDO SHOW DATABASE statement.  Previously, only the
|           database name was shown.
|  
|      20.  The following DIGITAL Standard Relational Interface
|           (DSRI) calls are supported in Rdb/VMS V2.3:
|  
|            -  BLR$K_DCL_VARIABLE
|  
|            -  BLR$K_VARIABLE
|  
|           Consult the DIGITAL Standard Relational Interface (DSRI)
|           Handbook for information about these calls.
|  
|      21.  New V2.3 code added to the Rdb/VMS Optimizer lets it
|           better determine the availablity of indexes to satisfy
|           queries.  In previous releases, you may have found that
|           the retrieval strategy for a query did not use the
|           index(es), even when it seemed appropriate to do so.
|  
|           For example, you may have found that you were able to
|           produce an indexed retrieval strategy by including a
|           Boolean predicate (WITH clause) that referenced index
|           segment(s) in an RSE.  Prior to Rdb/VMS V2.3, in cases
|           such as the following, Case 1 used a sequential


                                    1-6









                            SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|                                                Summary of V2.3 Features


|           retrieval strategy, whereas Case 2 used an indexed
|           retrieval strategy.  Case 2 did not require the sort
|           operation because the index provided the sorted order.
|  
|           Case 1:
|  
|            FOR JH IN JOB_HISTORY 
|               SORTED BY JH.EMPLOYEE_ID
|               PRINT JH.*
|            END_FOR
|  
|           Case 2:
|  
|            FOR JH IN JOB_HISTORY 
|              SORTED BY JH.EMPLOYEE_ID
|              WITH JH.EMPLOYEE_ID > 0
|              PRINT JH.*
|            END_FOR
|  
|           Starting in Rdb/VMS V2.3, the addition of the Boolean
|           predicate in Case 2 is unnecessary; in these examples,
|           when an index is defined for the JOB_HISTORY relation
|           and that index uses EMPLOYEE_ID as the key, the index
|           will be used.  The Rdb/VMS V2.3 Optimizer code may make
|           other workarounds you have found, unnecessary also.
|  
|  In addition to the new features and technical changes summarized
|  in the previous list, a number of changes were made to the V2.3
|  Relational Data Manipulation Language (RDML) and the RDML
|  preprocessor:
|  
|       1.  VAX C Varying String Macros
|  
|           Prior to Rdb/VMS V2.3, RDML/C used macros to declare
|           varying string data types in VAX C (these macros were
|           not documented).  These macros are no longer used by
|           RDML.  If you want to continue using them, place the
|           following statement in your source code before a
|           DATABASE statement is issued in any of your modules:
|  
|            define USE_OLD_RDML_MACROS
|  
|           For more information, see the VAX C include file in
|           SYS$LIBRARY:RDMLVAXC.H.  However, note that DIGITAL
|           recommends that you use the DEFINE_TYPE statement when
|           declaring varying string data types in RDML programs.
|  
|       2.  Storing segmented strings in PASCAL



                                    1-7









   SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|  Summary of V2.3 Features


|           The code for storing segmented strings in RDML PASCAL
|           has changed such that you no longer need to specify
|           either ".VALUE" or ".LENGTH" as part of the segmented
|           string variable.  For example, prior to Rdb/VMS V2.3,
|           the following code was necessary (where 'document' is an
|           array of character strings):
|  
|           STORE R IN RESUMES USING
|              R.EMPLOYEE_ID = '12345';
|              for linecnt := 0 to 2 do
|              STORE LINE IN R.RESUME
|                  LINE.VALUE :=document[linecnt]
|                 LINE.LENGTH := length(document[linecnt]);
|              END_STORE
|           END_STORE;
|  
|           The new code allows you to write the record selection
|           expression (RSE) either as shown in the previous example or
|           as:
|  
|           STORE R IN RESUME USING
|              R.EMPLOYEE_ID ='12345'
|              for linecnt := 0 to 2 do
|              STORE LINE IN R.RESUME USING
|                 LINE := document[linecnt];
|                   END_STORE;
|           END_STORE;
|  
|           Additionally, Rdb/VMS V2.3 lets you use the Rdb/VMS keywords
|           RDB$VALUE and RDB$LENGTH in RDML PASCAL and RDML C programs.
|           For example, in C programs:
|  
|           STORE R IN RESUMES USING
|              strcpy (R.EMPLOYEE_ID,"12345");
|              for (line = 0; line <= 2; line++) 
|                 STORE LINE IN R.RESUME
|               strcpy(LINE.RDB$VALUE,document[line]);
|                       LINE.RDB$LENGTH = strlen(LINE.VALUE);
|                 END_STORE;
|           END_STORE;
|  
|           In PASCAL programs:
|  
|           STORE R IN RESUMES USING
|              R.EMPLOYEE_ID = '12345';
|              for linecnt := 0 to 2 do
|              STORE LINE IN R.RESUME
|                  LINE.RDB$VALUE :=document[linecnt]
|                 LINE.RDB$LENGTH := length(document[linecnt]);


                                    1-8









                            SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|                                                Summary of V2.3 Features


|              END_STORE
|           END_STORE;

|  
|       3.  Additions to the DATABASE statement syntax
|  
|           The RDML DATABASE statement now allows an optional INVOKE
|           keyword before the DATABASE keyword.  For example:
|  
|               INVOKE DATABASE FILENAME "PERSONNEL";
|  
|       4.  Placement of the database handle and scope keywords
|  
|           Prior to Rdb/VMS V2.3, RDML required that the scope keywords
|           appear as:
|  
|               dbhandle = optional-scope-keyword
|  
|           RDML now allows either the preceding syntax, or the following
|           syntax:
|  
|              optional-scope-keyword dbhandle =
|  
|           For example, the following DATABASE statements are both
|           valid:
|  
|              DATABASE PERS = [GLOBAL] FILENAME "PERSONNEL";
|  
|              DATABASE [GLOBAL] PERS = FILENAME "PERSONNEL";
|  
|           Furthermore, the brackets enclosing scope keywords are now
|           optional.  (Prior to Rdb/VMS V2.3, RDML required that they
|           appear in brackets.) For example, all of the following are
|           valid:
|  
|              DATABASE GLOBAL PERS = FILENAME "PERSONNEL";
|  
|              DATABASE [EXTERNAL] PERS = FILENAME "PERSONNEL";
|  
|              DATABASE PERS = [EXTERNAL] FILENAME "PERSONNEL";
|  
|              DATABASE [GLOBAL] PERS = FILENAME "PERSONNEL";
|  
|              DATABASE EXTERNAL PERS = FILENAME "PERSONNEL"; 

|  
|       5.  BATCH_UPDATE added to RDML START_TRANSACTION statement
|  
|           The RDML START_TRANSACTION statement now allows a


                                    1-9









   SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|  Summary of V2.3 Features


|           BATCH_UPDATE transaction Prior to Rdb/VMS V2.3, BATCH_UPDATE
|           was not available in RDML.  The new syntax diagram for the
|           RDML START_TRANSACTION follows:
|  
|           START_TRANSACTION  ---+------------>-----------------+----->--------+
|                                 +-> (TRANSACTION_HANDLE var) --+              |
|             +--------------------------------<--------------------------------+
|             +-+------->---------+---+--------->-------+-+----->-----+--------+
|               +-> READ_ONLY  ---+   +-> CONSISTENCY --+ +-> WAIT   -+        |
|               +-> READ_WRITE ---+   +-> CONCURRENCY --+ +-> NOWAIT -+        |
|               +-> BATCH_UPDATE -+                                            |
|             +------------------------------<---------------------------------+
|             +---+->---------------------+---+-->-------------+-------------->
|                 +-> reserving clause ---+   +--> on-error ---+
|  
|  
|           For completeness, the warning about BATCH_UPDATE that appears
|           in the VAX Rdb/VMS Reference Manual is repeated here:
|  
|           You can reduce overhead in large initial load operations by
|           using a BATCH_UPDATE transaction .  To speed update
|           operations, Rdb/VMS does not write to any journal files in
|           BATCH_UPDATE mode.  Therefore, you cannot roll back a batch
|           update transaction; if the load fails, you must recreate the
|           database.  For example, if you need a large test database for
|           development purposes, BATCH_UPDATE mode loads the database,
|           but bypasses the journaling facilities.
|  
|           When you can specify the BATCH_UPDATE mode in your
|           START_TRANSACTION statement, the load or update task results
|           in access to the entire database.  BATCH_UPDATE, for example,
|           requires your transaction to be the only one accessing the
|           database.  It is the most efficient mode you can choose when
|           loading the entire database for the first time, or when you
|           batch database updates in a data file that you intend to
|           apply to the database at one time.
|  
|           In addition to requiring the fewest locks on the database,
|           BATCH_UPDATE permits updates to the database without creating
|           a run-unit journal file.  Therefore, any records changed or
|           added during the BATCH_UPDATE transaction cannot be rolled
|           back because Rdb/VMS does not maintain before-images of the
|           changed records.
|  
|           Before you begin a BATCH_UPDATE transaction in your programs,
|           you should create a backup copy of the database using the VMS
|           Backup (BACKUP) utility.
|  
|           If any error occurs during the BATCH_UPDATE transaction that


                                    1-10









                            SUMMARY OF TECHNICAL CHANGES AND NEW FEATURES
|                                                Summary of V2.3 Features


|           causes Rdb/VMS to automatically roll back (for example, a
|           constraint condition is violated), the database is
|           permanently corrupted.  You must recreate the database from
|           the backup copy of the database.  After you have corrected
|           the error condition, you can restart the program from the
|           beginning.
|  
|           RDML users who want to use the BATCH_UPDATE option should
|           first read the descriptions in the VAX Rdb/VMS Reference
|           Manual and the VAX Rdb/VMS Guide to Data Manipulation
|  








































                                     1-11




















                               CHAPTER 2

                         SOFTWARE ERRORS FIXED



|  This chapter describes software errors that have been corrected
|  in Rdb/VMS V2.2 and V2.3.  A vertical change bar ( | ) in the
|  left margin indicates material added in V2.3.



   2.1  Software Errors Fixed in Rdb/VMS V2.2

   The following sections describe problems with previous versions
   of the Rdb/VMS software that were fixed in V2.2.  These software
   problems no longer exist.



   2.1.1  Database Administration and Maintenance

   This section documents corrections to software errors that are
   related to database administration and maintenance.



   2.1.1.1  CDD Locking Contention Reduced - Prior to V2.2, the
   default node of the VAX CDD was being locked on a DEFINE DATABASE
   or RESTORE statement.  This caused contention on the default CDD
   node when more than one person was attempting to use that node
   during the time of the database definition or the restore
   operation.  For example, if a user's CDD$DEFAULT value was
   CDD$TOP.ACCOUNTING, a lock was taken out on that node and no
   other users could use it until after:

        1.  The DATABASE or RESTORE operation ended

        2.  The user exited from RDO

   With V2.2, Rdb/VMS releases the lock on CDD$DEFAULT and takes out


                                     2-1










   SOFTWARE ERRORS FIXED
   Software Errors Fixed in Rdb/VMS V2.2


   a new lock on the directory just created to hold the database.
   For example, if you are restoring a database called PERS, the
   sequence of events is:

        1.  Take out a lock on CDD$TOP.ACCOUNTING.

        2.  Create the directory for the new CDD object.

        3.  Release the lock on CDD$TOP.ACCOUNTING.

        4.  Take out a new lock on CDD$TOP.ACCOUNTING.PERS.

        5.  Write the restored PERS definitions to
            CDD$TOP.ACCOUNTING.PERS.

        6.  Do not release the lock on this node until after the
            restore operation completes and the user exits RDO.




   2.1.1.2  The RDMS$BIND_WORK_FILE Logical - The
   RDMS$BIND_WORK_FILE logical did not work properly in Rdb/VMS
   V2.1.

   This problem has been fixed.



   2.1.2  Failure of RESTORE with COMPUTED BY Fields

   Prior to V2.2, a RESTORE operation failed if it encountered a
   COMPUTED BY field that referenced a field from another relation
   that was not defined yet.  This software restriction has been
   fixed in V2.2.



   2.1.3  Monitor Processes

   Prior to V2.2, it was possible for two Rdb/VMS monitor processes
   to be started when two user processes accessed Rdb/VMS
   simultaneously.  This problem has been fixed.



   2.1.4  RDO Statements

   This section describes corrections to previous errors with RDO


                                     2-2









                                                      SOFTWARE ERRORS FIXED
                                      Software Errors Fixed in Rdb/VMS V2.2


   statements.  Note that corrections to DML statements are covered
   in the subsequent Data Manipulation section.



   2.1.4.1  EDIT Statement in RDO and EVE Editor - Prior to Rdb/VMS
   V2.2, you had to modify an EVESECINI section file before using
   EVE as the editor with the RDO EDIT statement.  (EVE is the
   Extensible VAX Editor, an interactive text editor written in the
   VAXTPU programming language.)

   The EDIT section in Chapter 6 of the VAX Rdb/VMS Reference Manual
   described the following workaround procedure:

   PROCEDURE EVE_READ_RDO_LINES
    READ FILE ('RDO$DUMMY_INPUT');
   ENDPROCEDURE;

   This procedure is no longer necessary.  Furthermore, this
   procedure will no longer work because the RDO$DUMMY_INPUT and
   RDO$DUMMY_OUTPUT names have been changed in Rdb/VMS V2.2 to
   RDO$EDIT_INPUT and RDO$EDIT_OUTPUT.



   2.1.4.2  PRINT Arithmetic Expressions in RDO - You can now use
   the PRINT statement in RDO to calculate arithmetic expressions
   without embedding the PRINT in a DML statement.  Prior to V2.2,
   an access violation could result from the following statement:

   RDO> DATA FILE PERSONNEL
   RDO> PRINT 1+1
   %SYSTEM-F-ACCVIO, access violation, reason mask=00, 
   A virtual address=00000001, PC=00000000, PSL=00000000

   To make this work prior to V2.2, you had to reference a database.
   For example:

   RDO> DATA FILE PERSONNEL
   RDO> FOR FIRST 1 E IN EMPLOYEES
   cont> PRINT 1+1  END_FOR

     2

   Starting in V2.2, this is not necessary.  For example:

   RDO> DATA FILE WORK$DISK:PERSONNEL
   RDO> print 1+2
                  


                                     2-3









   SOFTWARE ERRORS FIXED
   Software Errors Fixed in Rdb/VMS V2.2


              3   
   RDO> print "1+2"
          
    1+2   
   RDO> exit

   Example 5 on page 6-164 of the V2.1 VAX Rdb/VMS Reference Manual
   describes the software restriction that existed prior to V2.2.
   As stated in this section, the problem no longer exists.



   2.1.5  Data Manipulation

   This section describes corrections to data manipulation language
   (DML) statements.



   2.1.5.1  Immediately Erased Records and COMMIT Constraint Lists -
   A software error involving erased records and COMMIT constraint
   lists has been fixed.  Prior to Rdb/VMS V2.2, unexpected results
   could occur if all the conditions in the following list were
   true.

         o  The transaction was started with constraints being
            evaluated at COMMIT_TIME.

         o  Within the transaction, you stored a new record and,
            sometime later, you erased the same record.

         o  The constraint strategy chose to keep a list of all the
            database keys (DBKEYs) for the relations in the main RSE

   Due to a software error, the DBKEY for the erased record was not
   removed from the COMMIT constraint list.  Under the circumstances
   outlined in the previous list, the following error message was
   seen:

   %RDMS-E-NODBK, <dbkey> does not point to a data record

   This problem has been fixed.









                                     2-4









                                                      SOFTWARE ERRORS FIXED
                                      Software Errors Fixed in Rdb/VMS V2.2


   2.1.5.2  Using a Quoted Period in a Query - Previously, the
   following query would result in a syntax error because of the
   quoted period ("."):

   RDO> FOR SA IN SALARY_HISTORY WITH SA.SALARY_AMOUNT CONTAINING
   "."
   %RDO-W-LOO_FOR_STT, syntax error, looking for:
     .
     .
     .

   This software has been fixed to recognize all valid quoted
   strings as quoted strings.



   2.1.6  Programming

   This section documents corrections to software errors that are
   related to programming.



   2.1.6.1  Corrected Error Message for RDBPRE and /OBJECT - Prior
   to Rdb/VMS V2.2, if an RDBPRE user supplied an invalid directory
   specification as the parameter to a /OBJECT qualifier, a
   misleading error message was displayed.  For example, the valid
   directory name is [PERSONNEL], but the user enters [PERSONNLE]:

   $ RFOR :== $RDBPRE/FORTRAN
   $ RFOR/OBJECT=[PERSONNLE] COLLEGES.RFO
   %RDO-F-UNBTMPFIL, unable to open a temporary file called 
   INPUT>

   Starting in V2.2, the invalid file name is identified and
   secondary RMS messages are supplied.  See the following example.

   $ RFOR/OBJECT=[PERSONNLE] COLLEGES.RFO
   %RDO-F-UNBTMPFIL, unable to open a temporary file 
                     called DISK$:[PERSONNLE]COLLEGES.OBJ;
   -RMS-E-DNF, directory not found
   -SYSTEM-W-NOSUCHFILE, no such file



   2.1.6.2  Wrapping Long Comment Lines in RDBPRE - The command line
   used to invoke the RDBPRE precompiler is included in the
   commented out "Compilation Statistics" section that appears at
   the bottom of every RDBPRE output file.  Prior to V2.2, RDBPRE


                                     2-5









   SOFTWARE ERRORS FIXED
   Software Errors Fixed in Rdb/VMS V2.2


   would not wrap lines longer than 132 characters and, in the case
   of VAX FORTRAN, the source code would not compile successfully.
   Starting in V2.2, lines longer than 132 characters are wrapped to
   the next line.



   2.1.6.3  VAX BASIC DML and START_SEG_STRINGS - Prior to V2.2, an
   error resulted when you tried to compile a .BAS file that was
   precompiled by RDBPRE and contained the equivalent Digital
   Standard Relational Interface (DSRI) call for the
   START_SEGMENTED_STRING statement.  One of the required
   declarations, RDB$SEG_ID_<number>, was not generated by the
   RDBPRE precompiler.

   This problem has been fixed.



   2.1.6.4  Error Message Added to Catch Unsupported String
            Expressions
            Expressions - The VAX BASIC string concatenation
   character is the plus sign (+).  Previously, Rdb/VMS interpreted
   this character in string expressions to be addition and attempted
   to add the two values together.  This resulted in a data
   conversion error.  For example:

   %RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime
   -OTS-F-INPCONERR, input conversion error

   Starting in V2.2, the proper error is signaled and the following
   error message is returned:

   %RDO-F-UNSSTREXPR, unsupported string expression

   Note that in a VAX BASIC program containing Rdb/VMS DML
   statements, the following is valid:

        &RDB&    GET VAR = P.CITY + P.COUNTRY

   However, the next example show two cases of invalid BASIC DML
   code:

        &RDB&    STORE E.CITY = VAR1 + VAR2

        &RDB&    STORE E.CITY = VAR1 | VAR2






                                     2-6









                                                      SOFTWARE ERRORS FIXED
                                      Software Errors Fixed in Rdb/VMS V2.2


   2.1.7  Data Definition

   This section documents corrections to software errors that are
   related to data definition.



   2.1.7.1  Long Field Names Used with Views - The last character of
   a 31-byte field name that is used in a view will no longer be
   corrupted.



   2.1.7.2  Field Level Descriptions in Views - The V2.0 VAX Rdb/VMS
   Reference Manual indicated that the DEFINE VIEW command allowed
   text descriptions enclosed in "/*    */" characters to precede
   the field name.  A software error prevented this from occurring.
   This error has been fixed.  For example, the following definition
   is valid:

    DEFINE VIEW EMP_NAME
        DESCRIPTION IS /* A view for an employee's full name only */
        OF E IN EMPLOYEES.
        /* First name */      E.FIRST-NAME.
        /* Middle initial */  E.MIDDLE_INITIAL.
        /* Last name */       E.LAST_NAME.
    END EMP_NAME VIEW.



   2.1.7.3  Multisegmented Index Retrieval with Numeric Fields -
   Prior to V2.2, whenever a multisegment indexed retrieval was
   performed and the second through nth fields were numeric, the
   accuracy of the retrieval set could be incorrect.  This software
   error is fixed in V2.2
|  
|  
|  
|  2.2  Software Errors Fixed in Rdb/VMS V2.3
|  
|  The following sections describe problems with previous versions
|  of the Rdb/VMS software that were fixed in V2.3.  These software
|  problems no longer exist.
|  
|  
|  
|  2.2.1  DESCRIPTION IS Clause
|  
|  Prior to Rdb/VMS V2.3, several problems existed with the


                                     2-7









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  DESCRIPTION IS clause.  They are:
|  
|       1.  RDO BACKUP and RESTORE of the Database
|  
|           Rdb/VMS ignored the DESCRIPTION IS clause when the
|           database was backed up and restored with the RDO BACKUP
|           and RESTORE statements.
|  
|       2.  The DEFINE DATABASE statement
|  
|           The DEFINE DATABASE statement handled the DESCRIPTION IS
|           clause incorrectly, resulting in the storage of
|           incorrect data for the description.
|  
|       3.  The SHOW DATABASE statement
|  
|           The SHOW DATABASE statement displayed unintelligible
|           data if the database had been defined with an optional
|           DESCRIPTION IS clause.
|  
|  All of the preceding problems have been fixed in Rdb/VMS V2.3.
|  
|  
|  
|  2.2.2  CHANGE FIELD or CHANGE RELATION Statements
|  
|  Prior to Rdb/VMS V2.3, a CHANGE FIELD or CHANGE RELATION
|  statement could cause a bugcheck with the exception occurring at
|  FIND_SCOL, offset +34.  This has been known to occur when fields
|  involved in the change are F_floating or G_floating data types.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.3  NOT ANY Clause and Missing Values
|  
|  Prior to Rdb/VMS V2.3, a query containing a NOT ANY clause would
|  bugcheck if there were missing values in either of the streams
|  being matched.  For example, the following resulted in a bugcheck
|  when any matching DEPARTMENTS and/or EMPLOYEES fields contained
|  missing values:
|  
|  FOR D IN DEPARTMENTS WITH NOT ANY E IN EMPLOYEES WITH
|   D.DEPARTMENT_CODE = E.DEPARTMENT_CODE 
|   PRINT D.DEPARTMENT_CODE
|  END-F
|  
|  This problem has been fixed in Rdb/VMS V2.3.


                                     2-8









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|  2.2.4  The FIRST Clause Used with Statistical Expressions
|  
|  Under some circumstances, the FIRST clause, would return
|  incorrect results in pre-V2.3 versions of Rdb/VMS.  For example,
|  the following two queries are identical, with one exception; the
|  first query requests that only the last name field be printed,
|  while the second query requests that both the first name and the
|  last name fields of the EMPLOYEES relation be printed.
|  
|  Query 1:
|  
|  FOR FIRST (.25 * COUNT OF EE IN EMPLOYEES)
|   E IN EMPLOYEES
|       PRINT E.LAST_NAME
|  END_FOR
|  
|  Query 2:
|  
|  FOR FIRST (.25 * COUNT OF EE IN EMPLOYEES)
|   E IN EMPLOYEES
|       PRINT E.LAST_NAME,
|             E.FIRST_NAME
|  END_FOR
|  
|  Prior to Rdb/VMS V2.3, the first query correctly returned the
|  last name of one quarter of the employees in the EMPLOYEES
|  relation, however the second query returned every record in the
|  relation.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.5  Host Variables and Statistical Functions with RDBPRE
|  
|  Prior to Rdb/VMS V2.3, the RDBPRE precompiler incorrectly
|  returned the error RDO-E-WISHLIST, when all of the following was
|  true:
|  
|        o  A GET statement was used to assign the value returned
|           from a statistical expression to a host variable.
|  
|        o  The statistical expression operated on a database field
|           with a DATE data type.
|  
|        o  A WITH clause was part of the statistical expression.
|  
|  Under these conditions, the RDBPRE precompiler ascribed the data
|  type of one of the fields used in the WITH clause to the host


                                     2-9









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  variable intended to hold that DATE data type value.  If that
|  data type was less that 8 bytes long, the WISHLIST error was
|  generated.
|  
|  This problem has been fixed in Rdb/VMS V2.3.
|  
|  
|  
|  2.2.6  Issuing the FINISH Statement with a Database Handle
|  
|  Prior to Rdb/VMS V2.3, the error RDB-E-OPEN_TRANS was returned if
|  a database that had been invoked using a database handle was
|  finished by issuing the FINISH db-handle statement.
|  
|  This problem has been fixed in Rdb/VMS V2.3.
|  
|  
|  
|  2.2.7  Records Returned with the BETWEEN Clause and the WITH
|         Clause
|  
|  For Rdb/VMS V2.1, the BETWEEN clause was fixed to work regardless
|  of whether the first value specified was higher or lower in value
|  than the second value specified in the clause.  However, prior to
|  Rdb/VMS V2.3, the code did not function as expected.  When the
|  second value was lower in value than the first, the range was
|  treated as exclusive of the higher value.  When the second value
|  was higher in value than the first, the range was treated as
|  inclusive of the higher value.
|  
|  For example, in Rdb/VMS V2.1 and V2.2 the following query would
|  only print all employee identification numbers between 100 and
|  199.
|  
|  FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID BETWEEN "00200" AND "00100"
|     PRINT E.EMPLOYEE_ID
|  END_FOR
|  
|  In Rdb/VMS V2.3, the same query will print all employee
|  identification numbers between 100 and 200, as expected.
|  
|  Furthermore, the WITH clause in conjunction with relational
|  operators joined by the OR and AND logical operators, returned
|  incorrect results when the value specified in the OR clause met
|  the conditions of the first value expression.  For example, the
|  following record selection expression (RSE) returned incorrect
|  results:
|  
|  FOR E IN EMPLOYEES WITH


                                     2-10









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|     E.EMPLOYEE_ID >= "00100" AND 
|     E.EMPLOYEE_ID <= "00200" OR
|     E.EMPLOYEE_ID = "00250"
|         .
|         .
|         .
|  END_FOR;
|  
|  In the preceding example, when Rdb/VMS evaluated the third
|  expression (OR E.EMPLOYEE_ID = "00250"), it mistakenly assumed
|  that this record had already been retrieved when it met the
|  conditions of the first expression (E.EMPLOYEE_ID >= "00100").
|  Rdb/VMS did not take into account that the second value
|  expression (E.EMPLOYEE_ID <= "00200") restricted it from
|  retrieving this record.
|  
|  These problems have been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.8  The ERASE Statement and Constraint Violations
|  
|  Prior to Rdb/VMS V2.3, under certain circumstances, Rdb/VMS would
|  allow changes to a record even if those changes violated a
|  constraint defined on the database.  The problem occurred in
|  precompiled queries in which the DSRI BLR$K_SELECT construct was
|  generated, containing both a BLR$K_ERASE and a BLR$K_MODIFY
|  statement.  The only time the constraint was not evaluated was
|  when it referred to a combination of 2 or fewer relations and
|  aggregates.
|  
|  This problem has been fixed for Rdb/VMS V2.3
|  
|  
|  
|  2.2.9  Copying Varying Strings from One Relation to Another Using
|         RDBPRE or RDO
|  
|  Prior to Rdb/VMS V2.3, incorrect data was stored in the target
|  field when an attempt was made to copy varying string fields from
|  one relation to another in either an RDBPRE preprocessed program
|  or in RDO.
|  
|  This problem has been fixed for Rdb/VMS V2.3.







                                     2-11









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  2.2.10  Success Status Incorrectly Returned on START_TRANSACTION
|          Failures
|  
|  Prior to Rdb/VMS V2.3, a START_TRANSACTION statement referred to
|  multiple databases could return an incorrect success status when
|  the START_TRANSACTION statement failed.
|  
|  This situation was most common when there were concurrent
|  executions of the same program and a lock conflict occurred for
|  one of the program executions.  Under these conditions, program
|  execution would proceed, only to fail at some later point with
|  Rdb/VMS errors such as, READ_ONLY_TRANS and REQ_WRONG_DB.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.11  Accessing Multiple Databases in Callable RDO
|  
|  Prior to Rdb/VMS 2.3, RDB$INTERPRET did not correctly process
|  !VAL database handles in data manipulation language (DML)
|  statements for some programming languages.  These problems are
|  known to have occurred when the following was true:
|  
|        o  A program attempted to access more than one Rdb/VMS
|           database
|  
|        o  The program that used callable RDO was written in VAX
|           Ada
|  
|  Furthermore, RDB$INTERPRET did not properly support the !VAL
|  construct on the START_TRANSACTION statement.
|  
|  Both of these problems have been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.12  Leading Numerics in File Specifications
|  
|  There are many places in RDO syntax that call for quoted string
|  literals.  However, there exists code which attempts to recognize
|  a string even if the quotes are not supplied.  Prior to Rdb/VMS
|  V2.3, this code did not permit the use of leading numerics in
|  file specifications.
|  
|  Rdb/VMS now supports leading numerics for all file specifications
|  except Common Data Dictionary (CDD) path names.  Note that if you
|  try to use a leading numeric for an RDO string that is used as a
|  default CDD path name, you will receive a CDD error.


                                     2-12









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|  2.2.13  Instantiation Parameters
|  
|  Prior to Rdb/VMS V2.3, Rdb/VMS did not validate the DIGITAL
|  Standard Relational Interface (DSRI) instantiation parameters
|  that are passed on many request-related calls.  Rdb/VMS now
|  validates these parameters.  However, it still does not support
|  multiple instantiations of a request.  An attempt to start a
|  second instantiation of a request results in an RDB_IMP_EXC
|  exception.  Use of invalid instantiation parameters results in an
|  RDB_REQ_SYNC exception.
|  
|  Note that only programs that make direct calls to DSRI need to be
|  concerned with instantiation parameters.  See the Digital
|  Standard Relational Interface (DSRI) Handbook for more
|  information on instantiation.
|  
|  
|  
|  2.2.14  Nested FOR Loops and Incorrect Context Fixed
|  
|  Prior to V2.3 in RDO and RDBPRE precompiled programs, incorrect
|  context was possible within nested FOR loops.
|  
|  The problem occurred in a query containing nested FOR loops in
|  which an Rdb/VMS statement (such as MODIFY) in an inner loop
|  referred to a context variable declared in an outer loop; the
|  Rdb/VMS statement was executed in the context of the outer loop.
|  This occurred only when both of the following conditions were
|  true:
|  
|        o  No host language statement was contained within the
|           inner loop.
|  
|        o  No DML statement referring to the inner loop's context
|           variable was used in the inner loop.
|  
|  For example, consider the following query:
|  
|  FOR S IN SALARY_HISTORY
|      FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = S.EMPLOYEE_ID 
|                          AND E.EMPLOYEE_ID = 1
|          MODIFY S USING S.SALARY_AMOUNT = 10000 END_MODIFY
|      END_FOR
|  END_FOR
|  
|  The pre-V2.3 user submitted this query to modify the
|  SALARY_HISTORY.SALARY_AMOUNT field only for the employee whose
|  identification number was "1".  The software error in pre-V2.3
|  releases caused this query to modify all the records in the


                                     2-13









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  SALARY_HISTORY relation.
|  
|  The former workaround, adding a host language statement, or a
|  PRINT statement in RDO, yielded the desired behavior:
|  
|  FOR S IN SALARY_HISTORY
|      FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = S.EMPLOYEE_ID 
|                          AND E.EMPLOYEE_ID = 1
|          MODIFY S USING S.SALARY_AMOUNT = 10000 END_MODIFY
|          PRINT E.EMPLOYEE_ID
|      END_FOR
|  END_FOR
|  
|  In pre-V2.3 releases, this workaround query only modified the
|  SALARY_HISTORY record for the employees whose identification
|  number was "1".
|  
|  This software error has been fixed for RDB/VMS V2.3 and the
|  workaround is no longer required.
|  
|  
|  
|  2.2.15  BATCH_UPDATE No Longer Permits ROLLBACK
|  
|  BATCH_UPDATE transactions no longer allow you to issue an
|  explicit ROLLBACK statement.  Because BATCH_UPDATE works without
|  a run-unit journal file (generally, to speed initial load
|  operations), a rollback permanently corrupts the database file.
|  
|  Instead of permitting the ROLLBACK, Rdb/VMS issues a
|  RDB-E-NO_ROLLBACK error message and does not end the transaction.
|  See the VAX Rdb/VMS Reference Manual for more information.
|  
|  
|  
|  2.2.16  CDD Offset Problem Fixed
|  
|  Rdb/VMS V2.3 fixes a problem with the calculation of the Common
|  Data Dictionary (CDD) record offset.  Consequently, the following
|  software error will no longer occur.
|  
|  Prior to V2.3, a host language compile-time error could occur
|  when the program attempted to copy a relation (CDD record)
|  definition from the CDD and the following was true:
|  
|       1.  The relation contained two fields that were based on the
|           same global field definition.




                                     2-14









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|       2.  An RDO user had changed the data type and/or size of the
|           global field on which the two local relation fields were
|           based.
|  
|  When the relation is copied out of the CDD, (for example, a VAX
|  COBOL program performing a " COPY FROM DICTIONARY
|  'cdd-path-to-rdb-relation'  " statement), the compiler would
|  generate an error message about the second field.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.17  Unexpected Error Messages Returned
|  
|  In previous releases, under some circumstances, an error was
|  created by the code used to attach to a database.  This problem
|  was seen primarily in programs that implemented large DATATRIEVE
|  procedures.  In these cases, the attach to the database caused a
|  portion of a DATATRIEVE token block to be overwritten, resulting
|  in either a %DTR-F_HOPELESS error message, or a syntax error
|  message.  These error messages were not reported at the time of
|  database attach, but rather unpredictably during program
|  execution.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.18  Assigning RDB$MISSING to a Field Using the !VAL Construct
|          in Callable RDO
|  
|  Prior to Rdb/VMS V2.3, an attempt to assign the missing value to
|  a field using RDB$MISSING and the !VAL construct in callable RDO
|  resulted in a syntax error.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.19  FORTRAN Precompiler and Dimensioned Storage Areas
|  
|  In previous releases, the RDBPRE precompiler for VAX FORTRAN
|  improperly converted source code when a record was read into a
|  dimensioned storage area defined by a FORTRAN RECORD statement.
|  This caused compile-time problems when the dimensioned array of a
|  record structure was used with "<context-variable>.*" syntax.
|  This problem has been fixed in Rdb/VMS V2.3.



                                     2-15









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  Consider the following code fragments:
|  
|       RECORD/RELATION_A/BUF_A(DIMENSION SIZE)
|  
|              i = 1
|  
|              &RDB& FOR RA IN RELATION_A
|              &RDB&  WITH RA.ID = ITEM_ID
|              &RDB&  GET
|              &RDB&    ON ERROR
|                      call error routine
|              &RDB&    END_ERROR
|              &RDB&    BUF_A(I) = RA.*
|              &RDB&  END_GET
|  
|              i = i + 1
|  
|              &RDB& END_FOR
|  
|  Prior to V2.3, the resulting converted code in the .FOR file for
            _
|  the "&RDB BUF_A(I) = RA.*" statement was undimensioned field
|  references.
|  
|              BUF_A.FIELD1 = RDB FIELD REFERENCE
|              BUF_A.FIELD2 = RDB FIELD REFERENCE
|                "
|                "
|              BUF_A.FIELDN = RDB FIELD REFERENCE
|  
|  This resulted in a FORTRAN compiler error INVRECUSE.
|  
|  The software error has been fixed.
|  
|  
|  
|  2.2.20  Rdb/VMS V2.3 Virtual Memory Improvements
|  
|  Considerable internal improvements were made to ensure that
|  Rdb/VMS does not retain unused Virtual Memory (VM).  Long series
|  of INVOKE/FINISH pairs to a database should no longer cause
|  problems; in previous releases, this type of repeated operation
|  could exceed the process' page file quota (PGFLQUOTA).
|  
|  
|  
|  2.2.21  RDML Software Corrections
|  
|  This section describes corrections to the Relational Data
|  Manipulation Language (RDML) and the RDML preprocessor.


                                     2-16









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|  2.2.21.1  Using Field Names as Host Variables in Record
|            Definitions - Prior to Rdb/VMS V2.3, RDML returned a
|  fatal error if you defined a host variable record with a database
|  field name as part of the record definition.  For example, the
|  following PASCAL record definition:
|  
|  VAR
|     Hostrecord:    Record
|                    EMPLOYEE_ID : BASED ON EMPLOYEES.EMPLOYEE_ID
|                           .
|                           .
|                           .
|                    End;
|  
|  led to a fatal error when RDML PASCAL attempted to process the
|  following RSE:
|  
|  FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = Hostrecord.EMPLOYEE_ID
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.2  Detecting Field Names That Are Not Part of a Relation -
|  Prior to Rdb/VMS V2.3, RDML did not detect invalid or nonexistent
|  field names used in an RSE.  Instead of signaling the error, RDML
|  would report successful program preprocessing.
|  
|  This problem has been fixed for Rdb/VMS V2.3; RDML will now
|  return the error message RDML-E-FLD_NOT_DEFINED when an invalid
|  or nonexistent field name is used in an RSE.
|  
|  
|  
|  2.2.21.3  The ON ERROR Clause in RDML - RDML did not preprocess
|  the ON ERROR clause correctly when it was used with the
|  START_TRANSACTION or START_STREAM statement in Rdb/VMS V2.3.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.4  VAX C Escape Sequences - Prior to Rdb/VMS V2.3, some
|  escape sequences that used the backslash character (\) were not
|  correctly interpreted by RDML.  For example the following escape
|  sequences were not correctly interpreted:
|  
|        o  "\""



                                     2-17









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|        o  "\'"
|  
|        o  '\''
|  
|  This problem has been fixed for Rdb/VMS V2.3; the preceding
|  escape sequences will now be correctly interpreted by RDML.
|  
|  
|  
|  2.2.21.5  Semantics of the STORE Statement with Segmented Strings
|   - The semantics of the STORE statement with segmented strings
|  has been corrected.  Prior to Rdb/VMS V2.3, RDML could not
|  perform multiple stores to the same segmented string inside an
|  outer STORE or MODIFY block.  For example, the C code below would
|  have only stored a single segmented string.  It will now execute
|  correctly.
|  
|  DATABASE FILENAME 'personnel';
|  
|  main()
|  {
|  static char *text[10] = 
|      {"First line of resume  ",
|       "Second line of resume ",
|       "Last line of resume   "};
|  static char *other_text[10] = 
|      {"Modified First line of resume  ",
|       "Modified Second line of resume ",
|       "Modified Last line of resume   "};
|  int line;
|  
|  START_TRANSACTION READ_WRITE;
|  
|  STORE R IN RESUMES USING 
|      strcpy(R.EMPLOYEE_ID,"12345");
|              line = 0;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);
|          END_STORE;
|              line++;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);
|          END_STORE;
|              line++;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);


                                     2-18









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|          END_STORE;
|  END_STORE;
|  
|  FOR R IN RESUMES WITH R.EMPLOYEE_ID = "12345"
|      FOR LINE IN R.RESUME
|          printf("%s\n", LINE.VALUE);
|      END_FOR;
|  END_FOR;
|  
|  FOR R IN RESUMES WITH R.EMPLOYEE_ID = "12345"
|      MODIFY R USING
|              line = 0;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, other_text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);
|          END_STORE;
|              line++;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, other_text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);
|          END_STORE;
|              line++;
|          STORE LINE IN R.RESUME
|                  strcpy(LINE.VALUE, other_text[line]);
|                  LINE.LENGTH = strlen(LINE.VALUE);
|          END_STORE;
|      END_MODIFY;
|  END_FOR;
|  
|  FOR R IN RESUMES WITH R.EMPLOYEE_ID = "12345"
|      FOR LINE IN R.RESUME
|          printf("%s\n", LINE.VALUE);
|      END_FOR;
|  END_FOR;
|  
|  ROLLBACK;
|  
|  }
|  
|  
|  
|  2.2.21.6  The NOT Boolean Operator - Prior to Rdb/VMS V2.3, RDML
|  did not use the correct order of precedence when it encountered
|  the NOT Boolean operator.
|  
|  This problem has been fixed for Rdb/VMS V2.3.





                                     2-19









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  2.2.21.7  The Null Comment Character in RDML/PASCAL - Prior to
|  Rdb/VMS V2.3, the null comment ({}) was misinterpreted by RDML.
|  RDML did not recognize the closing brace unless at least one
|  space or character appeared between the brackets.  The null
|  comment is now correctly interpreted.
|  
|  
|  
|  2.2.21.8  Host Variables and the BETWEEN Conditional Expression -
|  Prior to Rdb/VMS V2.3, RDML returned an error when a BETWEEN
|  clause was formed using a host variable as the first argument to
|  the expression.  For example, the following code resulted in an
|  error message (where todays_date is a host language variable):
|  
|  FOR SH IN SALARY_HISTORY
|     WITH todays_date BETWEEN SH.SALARY_START 
|          AND SH.SALARY_END
|           .
|           .
|           .
|  END_FOR;
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.9  Number Sign (#) in C Character String Constants - Prior
|  to Rdb/VMS 2.3 the number sign (#) character was parsed out of
|  character string constants.
|  
|  This problem has been fixed for Rdb/VMS V2.3
|  
|  
|  
|  2.2.21.10  CDD Access Using the PATHNAME Option of the DATABASE
|             Statement - Prior to Rdb/VMS V2.3, under some
|  conditions, RDML returned the following error message when the
|  PATHNAME option was specified in the DATABASE statement:
|  
|  %RDML-F-RDML_ABORT, Fatal Preprocessor Utility Error
|           Aborted because: relation name overflowed buffer
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.11  Reserving Clause of the START_TRANSACTION Statement -
|  Prior to Rdb/VMS V2.3, when more than one database was included
|  in the DATABASE statement(s), RDML started a read-only


                                     2-20









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|  transaction for any databases that were not included in the
|  RESERVING clause of the START_TRANSACTION statement.
|  
|  This problem has been fixed; when you explicitly start a
|  transaction and use the RESERVING clause, RDML will only start a
|  transaction for the database you specify.
|  
|  
|  
|  2.2.21.12  Line Length of Generated Code - Code has been added to
|  the RDML preprocessor to shorten the line length of the generated
|  code.
|  
|  
|  
|  2.2.21.13  Transaction Parameter Block - Prior to Rdb/VMS V2.3,
|  RDML generated more transaction parameter block lock items than
|  needed.
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.14  Date Parameters for Statistical and Boolean Functions
|  -r Prior to Rdb/VMS V2.3, RDML returned incorrect values for
|  statistical or Boolean functions that passed a date parameter.
|  For example, the following code would generate incorrect results:
|  
|  FOR FIRST 5 E IN CURRENT_SALARY SORTED BY E.EMPLOYEE_ID
|    WRITELN ('people who have had salary reviews since, ');
|    WRITELN (COUNT OF E1 IN CURRENT_SALARY WITH E1.SALARY_START > E.SALARY_START,
|             ' ',E.FIRST_NAME, E.LAST_NAME);
|  END_FOR;
|  
|  RDML now produces the correct results under these conditions.
|  
|  
|  
|  2.2.21.15  Zero Termination of Text Values Returned from C Functions -
|  RDML/C now guarantees that text values returned from RDML/C-generated
|  functions will be terminated with a zero.  Prior to Rdb/VMS V2.3 this
|  was not guaranteed.
|  
|  
|  
|  2.2.21.16  RDML/PASCAL Word Data Types - Prior to Rdb/VMS V2.3, a
|  problem existed in the allocation size of word data types used by the
|  RDML/PASCAL preprocessor.  This problem affected applications that
|  referred to fields defined as a SIGNED WORD data type in the database,


                                     2-21









   SOFTWARE ERRORS FIXED
|  Software Errors Fixed in Rdb/VMS V2.3


|  or fields used to manipulate segmented strings.  These types were
|  generated in the output file of RDML/PASCAL as either:
|  
|  0..65535
|  
|  or
|  
|  -32768..32767
|  
|  without specifying the allocation size.  As a result, the type was
|  promoted to its natural (32 bit) size and was allocated as an integer
|  by the VAX PASCAL compiler.
|  
|  This problem has been fixed for Rdb/VMS V2.3
|  
|  
|  
|  2.2.21.17  DEFINE_TYPE Statement - Prior to Rdb/VMS V2.3, RDML would
|  drop all but the last of a list of variables supplied to the
|  DEFINE_TYPE statement.  For instance, RDML would ignore all the
|  variables except emp_id in the following example:
|  
|  DEFINE_TYPE OF id, number, emp_id SAME AS EMPLOYEES.EMPLOYEE_ID;
|  
|  RDML will now execute the DEFINE_TYPE code for all variables within a
|  list of variables supplied with the DEFINE_TYPE statement.
|  
|  
|  
|  2.2.21.18  The RDMLRTL and Multiple Databases and Transactions - Prior
|  to Rdb/VMS V2.3, problems in the code for the RDML Run-Time Library
|  (RDMLRTL) support routines created incorrect argument lists.  This
|  problem resulted in Rdb/VMS not being able to read certain arguments.
|  The user would receive the error message:
|  
|  %RDB-F-WRONUMARG, illegal number of arguments on call to Rdb system
|  
|  This problem has been fixed for Rdb/VMS V2.3.
|  
|  
|  
|  2.2.21.19  EPASCAL Function Parameters - Prior to Rdb/VMS V2.3,
|  EPASCAL function parameters were incorrectly declared by RDML.  For
|  example, the following code would not preprocess, because the
|  parameter EMP.EMP_ID, was incorrectly declared by RDML:
|  
|  FOR EMP IN EMPLOYEES
|   writeln (EMP.NAME, COUNT OF SH IN SALARY_HISTORY
|                      WITH SH.EMP_ID = EMP.EMP_ID);


                                     2-22









                                                      SOFTWARE ERRORS FIXED
|                                     Software Errors Fixed in Rdb/VMS V2.3


|  END_FOR;
|  
|  This problem has been fixed for Rdb/VMS V2.3.
















































                                     2-23




















                                 CHAPTER 3

               KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS



|  This chapter describes problems, restrictions, and workarounds known
|  to exist in this release.  Most of these problems were reported in
|  previous releases of Rdb/VMS.  A vertical change bar ( | ) in the left
|  margin indicates material added in V2.3.

   All Rdb/VMS users should read this chapter.



   3.1  Database Administration and Maintenance

   The following sections describe known problems, restrictions, and
   workarounds pertaining to database administration and maintenance.
|  
|  
|  
|  3.1.1  Null Field Designation May Be Lost Following BACKUP/RESTORE
|         Operation
|  
|  Information that a database field was defined as null may be lost
|  following an RDO BACKUP and RESTORE operation.  The DSRI specification
|  of the backup-restore protocol does not provide a way to preserve the
|  "nullness" of a field.  Therefore, the only option for Rdb/VMS is to
|  read the data provided (the missing value, if specified, or the
|  default missing value) and then to restore that value later.
|  
|  For fields with an explicit missing value, the restoration of the data
|  will trigger recognition of the match between data value and missing
|  value, and the null indicator will be set for the field.  For fields
|  without an explicit missing value, the default missing value (zero or
|  blanks) will be stored just as if it were "real data".






                                    3-1










   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Database Administration and Maintenance


   3.1.2  Unimplemented Access Rights

   The following access rights are not implemented for this software
   version:

         o  OPERATOR

         o  SHOW

   If you issue a SHOW PROTECTION statement for a database, these access
   rights are displayed, although they are not implemented.  Rdb/VMS does
   not return an error message if you attempt to deny these access
   rights, and they will not be displayed in the SHOW PROTECTION
   statement if you attempt to deny the access rights.



   3.1.3  Database Recovery

   Normally, attempts by unprivileged accounts to delete an .RUJ file
   will produce an error message, and the deletion will fail.  When
   Rdb/VMS needs to recover a database automatically after a system
   failure and cannot find an .RUJ file, the recovery fails and Rdb/VMS
   produces a bugcheck.  The event will be recorded in RDMMON.LOG.
   Therefore, you should never delete an .RUJ file; Rdb/VMS deletes all
   .RUJ files after it has completed automatic database recovery.

   If an .RUJ file has been deleted, and Rdb/VMS attempts automatic
   recovery, then that database will be corrupt.  To restore the database
   to an uncorrupt version, use the last backup version of the database
   and reapply all necessary changes.  If after-image journaling is
   enabled on the database, use the RDO RECOVER statement.  The RECOVER
   statement requires an uncorrupt backup version of the database to
   which the after-image journal files are applied.  Refer to the VAX
   Rdb/VMS Guide to Database Administration and Maintenance for more
   information on after-image journaling.

   If, for example, you enter a CTRL/Y in RDO, or your Rdb/VMS program
   does not handle a fatal error, your Rdb/VMS process terminates
   abruptly.  When your Rdb/VMS process terminates abruptly, the Rdb/VMS
   monitor begins a recovery process to roll back your uncommitted
   transactions.  The recovery process has the same name and UIC as your
   terminated process, but a different process ID.  Do not confuse the
   recovery process with your terminated process and attempt to stop the
   new process.






                                    3-2









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                  Database Administration and Maintenance


   3.1.4  Backup Utility

   Because Rdb/VMS does not check the OPERATOR access right, you need
   READ access to all the relations in the database (or sufficient VMS
   privileges) to back up the database.



   3.1.5  BACKUP and RESTORE Statements

   You should use a file extension when issuing the RDO BACKUP and
   RESTORE statements.  Using a file extension prevents an error which
   may be caused by the inconsistency in the syntax of the BACKUP and the
   RESTORE statements.

   The BACKUP statement does not require a period to terminate the
   command; however, the RESTORE statement does require a period as a
   statement terminator.  If you issue the BACKUP statement without a
   file extension, but with a period statement terminator, Rdb/VMS
   creates a backup file without a file extension.  The following BACKUP
   statement creates the file NEW-DBNAME.;1.

   RDO> BACKUP CURR-DBNAME NEW-DBNAME. 

   However, when you issue the following RESTORE statement, Rdb/VMS
   attempts to restore the file NEW-DBNAME.RBR, which does not exist.

   RDO> RESTORE NEW-DBNAME NEW-DBNAME. 

   Instead, use the .RBR file extension in the BACKUP and RESTORE
   statements.

   RDO> BACKUP CURR-DBNAME NEW-DBNAME.RBR
   RDO> RESTORE NEW-DBNAME.RBR NEW-DBNAME.
   Or, if you do not use the .RBR file extension in the BACKUP statement,
   you must specify the backed up database by its exact file name
   (NEW-DBNAME.;) in the RESTORE statement.

   RDO> RESTORE NEW-DBNAME.; NEW-DBNAME.



   3.1.6  Invalid Transaction Handle Using Multiple Databases

   The COMMIT ON ERROR ROLLBACK END_ERROR construct in a multiple
   database context may cause an error stating that the transaction
   handle is invalid.

   There are several steps that you can take to restrict the problem.


                                    3-3









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Database Administration and Maintenance


         o  Use multiple database in read-write transactions only when
            necessary.

         o  When multiple database read-write transactions are necessary,
            do not use constraints that are checked on commit.

         o  If it is necessary to check constraints on commit, declare
            that database whose constraints are to be checked on commit
            as the first database to be invoked.

         o  If it is necessary to have more than one database with
            constraints that are checked on commit, start and end the
            transactions for each database separately.  You can do this
            by calling separate, individual, routines to start
            transactions on each database and other routines to commit or
            roll back on each database.  Because the called routines do
            not know that there are two or more databases, Rdb/VMS does
            not return an error.  This method also requires the use of
            transaction handles.




   3.1.7  Using CHANGE DATABASE to Specify After-Image Journaling

   When you use the CHANGE DATABASE statement to specify after-image
   journaling, you must ensure that the database is closed.  See the
   description of CHANGE DATABASE ... OPEN IS {AUTO | MANUAL } in Chapter
   6 of the VAX Rdb/VMS Reference Manual for details.  If you issue the
   CHANGE DATABASE JOURNAL statement and the database is open, Rdb/VMS
   returns an error, FILACCERR.



   3.1.8  Using the SPOOL Command with an Empty AIJ File

   When you specify CONTINUOUS with the SPOOL command and the after-image
   journal file (file type .AIJ) does not currently contain any records,
   Rdb/VMS returns an EMPTYAIJ error and the spooling operation will
   terminate rather than continue at intervals.



   3.1.9  Limitation of the UNTIL Qualifier of the RECOVER Statement

   In the current implementation, you cannot supply the following VMS
   date keywords as values for the UNTIL qualifier of the RECOVER
   statement.



                                    3-4









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                  Database Administration and Maintenance


         o  YESTERDAY

         o  TODAY

         o  TOMORROW




   3.1.10  Stopping SPOOL Using CONTINUOUS Option with CONTROL-Y

   When you enter a CONTROL-Y to terminate continuous spooling of the
   after-image journal, you must also enter STOP at the DCL prompt.

   RDO> SPOOL DATABASE FILE PERSONNEL 
   cont> FILE IS DISK1:[DB.AIJ]PERS_AIJ.SPL
   cont> CONTINUOUS
   RDO> ^Y
   $ STOP
   $
|  
|  
|  
|  3.1.11  Problem Using VAX TEAMDATA V1.1 and Rdb/VMS V2.3.
|  
|  An error in TEAMDATA V1.1 makes Rdb/VMS V2.3 and TEAMDATA V1.1
|  incompatible.  Only TEAMDATA V1.2 will run correctly with Rdb/VMS
|  V2.3.



   3.2  Data Definition

   The following sections describe known problems, restrictions, and
   workarounds pertaining to data definition.
|  
|  
|  
|  3.2.1  DESCRIPTION IS Clause and SHOW INDEX Statement
|  
|  When you issue the SHOW INDEX statement in RDO, the text of the
|  DESCRIPTION IS clause is not displayed.  However, when you issue the
|  SHOW INDEX index_name statement, the text of the DESCRIPTION IS clause
|  will be displayed.  The following RDO session demonstrates these
|  differences:
|  
|  RDO>  DATA FILE PERSONNEL
|  RDO>  DEFINE INDEX STATE_IND DESCRIPTION IS /* TEMPORARY INDEX */ FOR EMPLOYEES.
|  cont> STATE.


                                    3-5









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Data Definition


|  cont> END STATE_IND.
|  %RDO-W-NOCDDUPDAT, database invoked by filename, the CDD will not be updated
|  
|  RDO> SHOW INDEX STATE_IND
    
|   Indexes for relation  EMPLOYEES                      
|  STATE_IND                          with field  STATE                          
|         description                temporary index 
|                                   Duplicates are allowed  
|  RDO> SHOW INDEX
|  User Indexes in Database with filename  personnel
    
|   Indexes for relation  COLLEGES                       
|  COLL_COLLEGE_CODE                with field  COLLEGE_CODE                   
|                                   No duplicates allowed  
    
|   Indexes for relation  DEGREES                        
|  DEG_COLLEGE_CODE                 with field  COLLEGE_CODE                   
|                                   Duplicates are allowed  
|  DEG_EMP_ID                       with field  EMPLOYEE_ID                    
|                                   Duplicates are allowed  
    
|   Indexes for relation  EMPLOYEES                      
|  NEW_IND                          with field  STATE                          
|                                   Duplicates are allowed  
    
|   Indexes for relation  JOB_HISTORY                    
|  JH_EMPLOYEE_ID                   with field  EMPLOYEE_ID                    
|                                   Duplicates are allowed  
    
|   Indexes for relation  SALARY_HISTORY                 
|  SH_EMPLOYEE_ID                   with field  EMPLOYEE_ID                    
|                                   Duplicates are allowed  
|  
|  
|  The workaround for this problem is to issue the SHOW INDEX index_name
|  statement when you want to see the text of the DESCRIPTION IS clause.
|  
|  
|  
|  3.2.2  CHANGE INDEX and DEFINE RELATION DISABLE COMPRESSION
|  
|  Rdb/VMS V2.3 added system fields named RDB$EXTENSION_PARAMETERS and
|  RDB$DATABASE_PARAMETERS to the system relations.  While the V2.3
|  software works with pre-V2.3 databases converted to the V2.3 software
|  (with the CONVERT statement in RDO), CONVERT does not add these system
|  fields to the system relations.  The DEFINE INDEX ...  NODE SIZE and
|  DEFINE RELATION ...  DISABLE COMPRESSION statements use those fields
|  and can only work with databases created by V2.3 software (using the


                                    3-6









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                          Data Definition


|  DEFINE DATABASE or RESTORE statements).
|  
|  Thus, if you converted your pre-V2.3 database using the CONVERT
|  statement, and you want to use the CHANGE INDEX, DEFINE INDEX ...
|  NODE SIZE, and DEFINE RELATION ...  DISABLE COMPRESSION features, back
|  up your database with the RDO BACKUP statement and use the RDO RESTORE
|  statement to add the required system fields.
|  
|  
|  
|  3.2.3  Do Not Use System Fields in User-Defined Relations
|  
|  The Rdb/VMS BACKUP statement will not allow Rdb/VMS system fields in
|  user-defined relations.  The FLDNOTBCK error message is returned
|  during the backup operation.  For example:
|  
|  RDO> DEFINE DATABASE 'XYZ'.
|  RDO> DEFINE FIELD RDB_FIELD_MASK DATATYPE TEXT SIZE 50.
|  RDO> DEFINE RELATION RDB_FIELDS.
|  RDO>        RDB$FIELD_NAME.
|  RDO>        RDB_EDIT_LENGTH BASED ON RDB$FIELD_LENGTH.
|  RDO>        RDB_FIELD_MASK.
|  RDO> END.
|  RDO> COMMIT
|  RDO> FINISH
|  RDO> BACKUP 'XYZ' 'XYZ_BACKUP.RBR'
|  %RDO-I-DELBACKUP, BACKUP errors, backup file deleted
|  %RDO-E-FLDNOTBCK, global field DB_EDIT_LENGTH RDB$FIELD_LENGTH
|  not defined as specified
|  
|  Do not define fields based on system fields.
|  
|  
|  
|  3.2.4  CHANGE and DELETE FIELD Statements and Views
|  
|  For a given database, you cannot issue a CHANGE FIELD or DELETE FIELD
|  statement for a field that is used in any view.  To change a field
|  used in a view, first delete the view definition, issue the CHANGE
|  FIELD or DELETE FIELD statement, and then (if desired) redefine the
|  view.



   3.2.5  Limitation on the Length of Description Clauses

   Rdb/VMS limits the length of a token to 1024 characters.  The
   description clause in a data definition statement is treated currently
   as one token.  Therefore, description clauses longer than 1024


                                    3-7









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Data Definition


   characters cause an error.



   3.2.6  Multiple Clauses in a DEFINE FIELD Statement

   The results are unpredictable if you use multiple, conflicting
   (redundant) clauses in field definitions.  In the following example,
   Rdb/VMS only recognizes the second VALID IF clause:

   DEFINE FIELD FX VALID IF FX > 0 VALID IF FX < 100.



   3.2.7  Using COMPUTED BY Fields in a DEFINE VIEW Statement

   You cannot define a COMPUTED BY field that refers to another local
   field in the view.  The following is incorrect:

   DEFINE VIEW WEEKLY_SALS OF SH IN SALARY_HISTORY.
     LOC_SALARY FROM SH.SALARY_AMOUNT.
     WEEKLY_SALARY COMPUTED BY (LOC_SALARY / 52).
   END WEEKLY_SALS VIEW.

   Instead, refer to the field itself:

   DEFINE VIEW WEEKLY_SALS OF SH IN SALARY_HISTORY.
     LOC_SALARY FROM SH.SALARY_AMOUNT.
     WEEKLY_SALARY COMPUTED BY (SH.SALARY_AMOUNT / 52).
   END WEEKLY_SALS VIEW.



   3.2.8  DEFINE DATABASE Statement

   If you are defining a database in RDO, do not spawn a subprocess to
   run VAX DATATRIEVE and attempt to ready the same database through
   DATATRIEVE.  Because the DEFINE statement in RDO causes the current
   process to hold locks, you must finish or commit the transaction
   before you spawn the DATATRIEVE subprocess.



   3.2.9  DELETE DATABASE Statement

   The following sequence of statements requires a pause between the
   FINISH statement and the DELETE statement:

   RDO> DEFINE DATABASE TESTDB.


                                    3-8









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                          Data Definition


   RDO> FINISH.
   RDO> DELETE DATABASE PATHNAME TESTDB.

   The pause is required because the DELETE statement is issued before
   the Rdb/VMS monitor has unbound from the database.  In a DCL command
   file, you can use the DCL WAIT statement to ensure a pause.



   3.3  Data Manipulation

   The following sections describe known problems, restrictions, and
   workarounds pertaining to data manipulation.
|  
|  
|  
|  3.3.1  Concatenation Operator with a Signed Longword Field
|  
|  When the concatenation operator is used with a signed longword field
|  from more than one relation in a nested query, incorrect data may be
|  returned.  Note the data returned in the following example; when the
|  concatenation operator is not used, a value of zero is returned for
|  D.BUDGET ACTUAL.  When the concatenation operator is used, an
|  incorrect value is returned.
|  
|  RDO>  FOR first 1 D IN DEPARTMENTS 
|  cont>       FOR first 1 E IN EMPLOYEES 
|  cont>        PRINT E.LAST_NAME | D.BUDGET_ACTUAL, E.LAST_NAME,D.BUDGET_ACTUAL
|  cont>       END_FOR
|  cont> END_FOR
|  
|   Aames        538976304     Aames                        0   
|  
|  A workaround for this problem is to multiply the concatenated fields
|  by 1.  For example:
|  
|          FOR FIRST 1 D IN DEPARTMENTS
|             FOR FIRST 1 E IN EMPLOYEES
|                PRINT E.LAST_NAME | D.BUDGET_ACTUAL*1
|             END_FOR
|          END_FOR
|  
|  
|  
|  3.3.2  Using SORTED with FIRST Statement and Statistical Expressions
|  
|  The SORTED clause may not behave as expected when used with a
|  statistical expression embedded in the FIRST clause.  The expected
|  behavior for Rdb/VMS is to:


                                    3-9









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Data Manipulation


|       1.  Sort the records in the relation specified by the RSE
|  
|       2.  Retrieve the number of records (as determined by the
|           statistical expression) from the sorted relation
|  
|  Instead, Rdb/VMS may first retrieve the number of records specified by
|  the statistical expression, and then sort the records that have been
|  retrieved.  This leads to unexpected results.
|  
|  In the following example, unless an index is defined on both the
|  LAST_NAME and the FIRST_NAME fields, Rdb/VMS will first retrieve one
|  quarter of the records from the EMPLOYEES relation and then sort these
|  records based on LAST_NAME:
|  
|  FOR FIRST (.25 * COUNT OF E IN EMPLOYEES)
|   E IN EMPLOYEES
|   SORTED BY E.LAST_NAME
|      PRINT E.LAST_NAME, E.FIRST_NAME
|  END_FOR
|  
|  The workaround for this problem is to define an index on all the
|  fields you intend to retrieve.  For example:
|  
|  DEFINE INDEX EMP_NAME FOR EMPLOYEES
|    LAST_NAME.
|    FIRST_NAME.
|  END EMP_NAME INDEX.
|  
|  
|  
|  3.3.3  Views and Conditional Expressions
|  
|  Queries that reference views and are qualified by conditional
|  expressions could result in incorrect record streams.
|  
|  The following example illustrates the problem.  The example defines a
|  view and then retrieves records from it.  One retrieval shows a simple
|  retrieval using the view; the other view retrieval is with a
|  conditional expression.  The conditional expression is applied
|  incorrectly and an invalid record stream results.
|  
|  The error occurs due to the way view queries are compiled.  First, the
|  view is expanded to include the relations named in the view definition
|  and then another conditional expression is applied.  Because the
|  queries are evaluated from left to right, the user's conditional
|  expression is applied last - too late to correctly restrict the
|  records.
|  
|  RDO> INVOKE DATABASE FILENAME PERSONNEL


                                    3-10









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                        Data Manipulation


|  RDO> START_TRANSACTION READ_WRITE
|  RDO> DEFINE VIEW viewed_with
|  cont>       OF C IN employees
|  cont>       WITH C.SEX = 'M'
|  cont>       AND C.EMPLOYEE_ID <> ''
|  cont>       AND NOT ANY
|  cont>        CX IN employees
|  cont>        WITH C.EMPLOYEE_ID = CX.EMPLOYEE_ID
|  cont>        AND CX.BIRTHDAY = MIN CZ.BIRTHDAY
|  cont>          OF CZ IN EMPLOYEES
|  cont>          WITH  CX.EMPLOYEE_ID = CZ.EMPLOYEE_ID.
|  cont>       C.EMPLOYEE_ID.
|  cont> END VIEW.
|  %RDO-W-NOCDDUPDAT, database invoked by filename, the CDD will not be updated
|  RDO> 
|  RDO> FOR FIRST 1 R IN EMPLOYEES PRINT R.* END-FOR
|   EMPLOYEE_ID   LAST_NAME        FIRST_NAME   MIDDLE_INITIAL   
|      ADDRESS_DATA_1              ADDRESS_DATA_2              
|         CITY                   STATE   POSTAL_CODE   SEX   
|            BIRTHDAY                  STATUS_CODE   
|   00164         Toliver          Alvin        A                
|      146 Parnell Place                                       
|         Chocorua               NH      03817         M     
|            28-MAR-1947 00:00:00.00   1             
    
|  RDO> 
|  RDO> FOR FIRST 1 R IN EMPLOYEES WITH R.EMPLOYEE_ID <> "00164" PRINT R.* END-F
|   EMPLOYEE_ID   LAST_NAME        FIRST_NAME   MIDDLE_INITIAL   
|      ADDRESS_DATA_1              ADDRESS_DATA_2              
|         CITY                   STATE   POSTAL_CODE   SEX   
|            BIRTHDAY                  STATUS_CODE   
|   00165         Smith            Terry        D                
|      120 Tenby Dr.                                           
|         Chocorua               NH      03817         M     
|            15-MAY-1954 00:00:00.00   2             
    
|  RDO> 
|  RDO> FOR T IN VIEWED_WITH
|  cont>       PRINT T.*
|  cont> END_FOR
|  RDO> 
|  RDO> FOR T IN VIEWED_WITH WITH T.EMPLOYEE_ID <> "00164"
|  cont>       PRINT T.*
|  cont> END_FOR
|   EMPLOYEE_ID   
|   00164         
|  
|  RDO>



                                    3-11









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Data Manipulation


   3.3.4  Update Rules Violated in RDO and Callable RDO

   The Rdb/VMS DML update rules require that a query cannot update a
   field if that field is mentioned in a CROSS clause.  Currently, an
   Rdb/VMS software error lets a query of this type using streams violate
   the rule in RDO and in any Callable RDO program.

   Fields that are mentioned in a CROSS clause should be considered
   read only by RDO.  The following error message should be (but
   currently is not) returned when an RDO user or a Callable RDO program
   attempts to update a read-only field:

   %RDB-E-READ_ONLY_FIELD, attempt to update read only field <fld-name>

   The following RDO example shows how a query that uses a CROSS clause
   can update the EMPLOYEE_ID field and result in inconsistent data
   between the EMPLOYEES relation and the SALARY-HISTORY relation.

   RDO> START-TRAN READ-WRITE
   RDO> START-STREAM ES USING E IN EMPLOYEES CROSS 
   cont> S IN SALARY-HISTORY WITH
   cont> E.EMPLOYEE-ID = S.EMPLOYEE-ID 
   RDO> FETCH ES
   RDO> PRINT E.EMPLOYEE-ID,E.LAST-NAME,S.EMPLOYEE-ID
    E.EMPLOYEE_ID   E.LAST_NAME      S.EMPLOYEE_ID   
    00164           Toliver          00164           
   RDO> !
   RDO> MODIFY S USING S.EMPLOYEE-ID = "12345"
   cont> END-MODIFY
   RDO> !
   RDO> PRINT E.EMPLOYEE-ID, E.LAST-NAME, S.EMPLOYEE-ID
    E.EMPLOYEE_ID   E.LAST_NAME      S.EMPLOYEE_ID   
    00164           Toliver          12345           
   RDO> END-STREAM ES
   RDO> !
   RDO> ! Notice that E.EMPLOYEE_ID = 164
   RDO> ! while S.EMPLOYEE_ID = 12345
   RDO> !
   RDO> ROLLBACK

   Do not update fields mentioned in a CROSS clause.



   3.3.5  Ambiguous Context Variable Names in FIRST Clause

   Rdb/VMS 2.0 extended the syntax to allow spaces in the specification
   of floating point literals.  As a result, it is possible to construct
   a query using the FIRST clause containing an ambiguous expression


                                    3-12









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                        Data Manipulation


   segment.  For example, the following query includes a FIRST 1 clause
   followed by a legal context variable, E37.  RDO can interpret such an
   expression as a floating point literal.

       FOR FIRST 1 E37 IN REL PRINT E37.* END_FOR
                |_____|
                   |
                   Can be interpreted as floating point literal




   3.3.6  Statistical Expressions with Complex Views

   Queries using statistical expressions applied to complex views (views
   that combine more than one relation) within FOR loops return erroneous
   results.  This error occurs when the view is defined on more than one
   relation.

   The following query returns erroneous results:

   FOR C IN SALARY_HISTORY 
     WITH C.SALARY_AMOUNT = MIN C1.SALARY_AMOUNT OF C1 IN CURRENT_SALARY
     PRINT C.*
   END-FOR

   To obtain correct results, substitute the view's definition in place
   of its name.



   3.3.7  Maximum Number of Subquery or Relation References

   The maximum number of subqueries or relation references in an Rdb/VMS
   statement is 32.  A subquery is a nested FOR statement.  A relation
   reference can be any of the entities in the following list.

         o  A relation in an RSE

         o  A global aggregate

         o  A relation in a multirelation view




   3.3.8  Storing Data in Views

   You can update and retrieve information from single relation views.


                                    3-13









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Data Manipulation


   You can only retrieve information from multirelation views.  You
   cannot update information using multirelation views.



   3.3.9  Using ANALYZE with Data Manipulation Statements

   The following sequence of RDO statements may generate a bugcheck dump:

   START_TRANSACTION READ_WRITE
   ANALYZE INDICES
   [any update statement]

   To avoid this problem, reserve the relations (using the RESERVING
   clause) to be updated for any update mode in the START_TRANSACTION
   statement.  You may then perform the ANALYZE statement and the update
   operations in the above sequence.



   3.3.10  Using the ERASE Statement with a CROSS Clause

   You may erase records from more than one relation by forming a record
   stream with a CROSS clause that joins several relations.  However, if
   you use the ERASE statement with a CROSS clause that joins one record
   to many, you must be careful to erase only unique records.

   For example, when you cross the EMPLOYEES relation with the
   DEPARTMENTS relation over the field DEPARTMENT_CODE, you form a record
   stream containing one record for each EMPLOYEE_ID.  However, since a
   number of employees work in each department, this record stream
   contains a number of records that include the same DEPARTMENT_CODE.

   You can erase all of the records in this stream using a context
   variable that points to unique EMPLOYEES records.  However, if you
   want to erase the records in this stream using a context variable that
   points to the multiple DEPARTMENTS records, you must first use the
   REDUCED TO clause to make the DEPARTMENTS records unique.  The
   following ERASE statement uses the context variable E to erase each
   record in the stream:

   FOR D IN DEPARTMENTS CROSS E IN EMPLOYEES OVER DEPARTMENT_CODE
       ERASE E
   END_FOR

   To erase records in this record stream using the context variable D,
   you must first use the REDUCED TO clause to reduce each
   DEPARTMENT_CODE to a unique record.  If you attempt to erase multiple
   DEPARTMENT_CODE records, the query will fail with the error


                                    3-14









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                        Data Manipulation


   RDMS-F-NODBK.  The following RSE correctly uses the REDUCED TO clause
   to reduce the DEPARTMENT_CODE records before the stream is erased:

   FOR D IN DEPARTMENTS CROSS E IN EMPLOYEES OVER DEPARTMENT_CODE
           REDUCED TO D.DEPARTMENT_CODE
       ERASE D
   END_FOR

   If you want to erase all duplicate DEPARTMENT_CODE records in the
   record stream, you should use nested FOR statements to create two
   separate streams for DEPARTMENTS and EMPLOYEES.  The following example
   erases the department FOO and all associated employees in that
   department:

   FOR D IN DEPARTMENTS WITH D.DEPARTMENT_CODE = 'FOO'
       FOR E IN EMPLOYEES 
         WITH D.DEPARTMENT_CODE = E.DEPARTMENT_CODE
             ERASE E
       END_FOR
         ERASE D
   END_FOR



   3.3.11  Processing Large Expressions

   When a VALID IF expression causes too many levels of recursion (more
   than 256), the following error message will be displayed:

   RDB$_IMP_EXC, implementation specific limit exceeded
   RDMS$_XPR_STACK_OFLOW, expression forces too many levels of recursion

   To avoid this situation, you should break up expressions into smaller
   subexpressions using parentheses.  Thus, do not define the expression
   as:

   DEFINE FIELD FOO DAT SIGNED LONG VALID IF
   FOO =1 OR FOO =2 ... OR FOO=3 OR FOO=4... 

   You should define it as:

   DEFINE FIELD FOO DAT SIGNED LONG VALID IF
   (FOO =1 OR FOO =2 OR ...) OR (FOO=3 OR FOO=4...)
|  
|  
|  
|  3.4  Rdb/VMS Documentation Errors or Omissions
|  
|  This section lists Rdb/VMS documentation errors.


                                    3-15









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
|  Rdb/VMS Documentation Errors or Omissions


|  3.4.1  Command Recall in RDO and CTRL/Z
|  
|  Entering CTRL/Z during an RDO session clears the RDO recall buffer in
|  Rdb/VMS V2.3.  If you enter CTRL/Z during an RDO session, you will not
|  be able to recall any of the commands you have entered up to that
|  point during the session.
|  
|  
|  
|  3.4.2  Updating a Relation Already Reserved in Shared Read Mode
|  
|  When the optimizer chooses a sequential scan strategy for searching a
|  relation reserved for shared read, Rdb/VMS places a PROTECTED lock on
|  the relation.  This effectively keeps all other users from updating
|  any record in the relation until the shared read transaction is
|  committed.  However, a process only locks the records it selects when
|  the optimizer chooses an indexed retrieval strategy.  Under these
|  conditions, one process can read records from a relation reserved
|  using shared read, while another process can update different records
|  from the same relation.  If you want to allow for concurrent updates
|  while a relation is reserved for shared read, include the SORTED BY
|  clause in your request.  Note that the field specified in the SORTED
|  BY clause must be an indexed field in order to produce an indexed
|  retrieval strategy.  For example, the following RSE will result in a
|  sequential scan of the EMPLOYEES relation, effectively locking the
|  entire EMPLOYEE relation against update:
|  
|  FOR FIRST 1 E IN EMPLOYEES
|    PRINT E.LAST_NAME
|  END_FOR
|  
|  Assuming that the EMPLOYEES relation has an index defined on the
|  EMPLOYEE_ID field, the following RSE will result in an indexed
|  retrieval strategy, which will allow other processes to update all
|  records except the one retrieved by this RSE:
|  
|  FOR FIRST 1 E IN EMPLOYEES
|     SORTED BY E.EMPLOYEE_ID
|       PRINT E.LAST_NAME
|  END_FOR
|  
|  
|  
|  3.4.3  Declaring Host Variables for STARTING WITH, MATCHING, and
|         CONTAINING in RDBPRE Programs
|  
|  Rdb/VMS transmits the comparison string of the STARTING WITH,
|  MATCHING, and CONTAINING conditional expressions as a VARYING STRING
|  data type.  This data type carries the length of the string as a


                                    3-16









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
|                               Rdb/VMS Documentation Errors or Omissions


|  two-byte integer at the start of the string.
|  
|  If a comparison string is coded as a string literal, as in the
|  following example, RDBPRE will transmit the comparison values as a
|  varying string of the appropriate length:
|  
|  FOR E IN EMPLOYEES WITH E.STATE MATCHING 'NH'
|  
|  If, however, your comparison string is a host variable of
|  indeterminate length, (for example, if state_code in the following
|  example is entered interactively), then you should declare your host
|  variable in such a way that the precompiler can determine the correct
|  length of the comparison string.
|  
|  FOR E IN EMPLOYEES WITH E.STATE MATCHING state_code
|  
|  In VAX BASIC, simply declare your host variable as a string.  The
|  precompiler will use the VAX BASIC function LEN to determine the
|  length of the varying string that is passed to the database.  For
|  example:
|  
|  100  DECLARE STRING state_code, name, city
|  
|       [program statements]
|       [Rdb/VMS statements:
|        invoke database, start_transaction, etc.]
|               .
|               .
|               .
|  &RDB& FOR E IN EMPLOYEES WITH
|  &RDB&    E.STATE MATCHING state_code
|  &RDB&   GET
|  &RDB&      name = E.LAST_NAME;
|  &RDB&      city = E.CITY
|  &RDB&   END_GET
|  
|  In VAX FORTRAN, you should declare the host variable as a string, and
|  then use the substring feature ("state_code(1:2)" for example) in your
|  RSE statement.  The substring will permit the precompiler, using the
|  VAX FORTRAN function LEN, to determine the length of the string.  For
|  example:
|  
|  IMPLICIT NONE
|  CHARACTER*15 name, city
|  CHARACTER*4 state_code
|  
|       [program statements]
|       [Rdb/VMS statements:
|          invoke database, start transaction, etc.]


                                    3-17









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
|  Rdb/VMS Documentation Errors or Omissions


|               .
|               .
|               .
|  &RDB& FOR E IN EMPLOYEES WITH
|  &RDB&      E.STATE MATCHING state_code(1:2)
|  &RDB&   GET
|  &RDB&      name = E.LAST_NAME;
|  &RDB&      city = E.CITY
|  &RDB&   END_GET
|  
|  In VAX COBOL, the declaration of the host variable is more complex.
|  VAX COBOL does not have a function that determines the length of a
|  string.  You must provide a numeric field to contain the length of the
|  comparison string.  Declare your host variable as a structure that
|  begins with a two-byte USAGE IS COMPUTATIONAL field, followed by a
|  field to contain the comparison string.  Then use this host variable
|  in your RSE statement.  See the following example.
|  
|  WORKING-STORAGE SECTION.
|  
|  01 DATUMS.
|     05 NAME    PIC X(15) USAGE DISPLAY.
|     05 CITY    PIC X(15) USAGE DISPLAY.
|     05 STATE-CODE.  
|        10 LEN-PART  PIC 9(4) USAGE COMP.
|        10 STRING-PART  PIC X(5) USAGE DISPLAY.
|           .
|           .
|           .
|       [Other declarations, invoke database]
|  
|  PROCEDURE DIVISION.
         
|      [program statements]
|           .
|           .
|           .
|  PARA-A.
|        MOVE 'NH' TO STRING-PART OF STATE-CODE.
|        MOVE 2 TO LEN-PART OF STATE-CODE.
|        &RDB& FOR E IN EMPLOYEES WITH
|        &RDB&      E.STATE MATCHING STATE-CODE
|        &RDB&   GET
|        &RDB&      NAME = E.LAST-NAME;
|        &RDB&      CITY = E.CITY
|        &RDB&   END-GET
|            DISPLAY NAME, ' ', CITY
|        &RDB& END_FOR



                                    3-18









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   3.5  Programming

   The following sections describe known problems, restrictions, and
   workarounds pertaining to programming.



   3.5.1  Do Not Parse Message Text to Retrieve Formatted FAO Arguments

   This release note affects you if all of the following conditions are
   true:

         o  You are creating an application that retrieves information
            returned by the VMS message vector for error conditions

         o  Your application returns messages customized for the user of
            your application

         o  Your application's message text includes formatted FAO
            arguments included in RDB, RDMS, and RDO facility error
            messages

   In this case, do not retrieve the entire RDB, RDMS, or RDO message
   text string (with formatted FAO arguments included) and then parse
   characters in the text string to locate and retrieve the substitution
   value for the FAO argument.

   Message text supplied by DIGITAL products is subject to change from
   one version of a product to another.  Text changes may be made to
   improve message clarity or make corrections to text that is
   misleading.  If your application parses RDB, RDMS, or RDO facility
   message text (thereby expecting the number of characters before and
   between FAO substitution values to remain constant), a future release
   of a VAX Rdb/VMS may cause your application to fail.

   To retrieve formatted values for FAO arguments to use in text that you
   supply, follow the instructions provided in the System Routines volume
   of the VMS documentation set.  These instructions explain the strategy
   supported by DIGITAL products using the VMS message vector.

   Please note that to ensure upward compatibility of your application
   from one version of VAX Rdb/VMS to another, any future changes to RDB,
   RDMS, or RDO message text will not affect:

         o  The ordinal position of error messages in the message files

         o  The number of FAO substitution arguments embedded in the text
            of a message



                                    3-19









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


         o  The order in which FAO substitution arguments occur in the
            text of a message

|  
|  
|  
|  3.5.2  FORTRAN Precompiler and Subscripted Record Data Types
|  
|  When using the FORTRAN precompiler for a subscripted record data type,
|  you will receive an error message.  For example, the following code
|  will generate an error:
|  
|       &RDB&  FOR J IN JOB_HISTORY WITH J.EMPLOYEE_ID = JOB(1).EMPLOYEE_ID
|  
|  The workaround for this problem is to define the subscripted record as
|  a character data type.  You may then use this value in the record
|  selection expression (RSE) as follows:
|  
|  CHARACTER*5 JOB_1_EMPLOYEE_ID
|           .
|           .
|           .
|  JOB_1_EMPLOYEE_ID = JOB(1).EMPLOYEE_ID
|  &RDB&  FOR J IN JOB_HISTORY WITH J.EMPLOYEE_ID = JOB_1_EMPLOYEE_ID
|           .
|           .
|           .
|  &RDB&  END_FOR  



   3.5.3  Precompiled Programs

   The following sections describe known problems, restrictions, and
   workarounds pertaining to precompiled programs.
|  
|  
|  
|  3.5.3.1  RDML Restrictions - This section describes current
|  restrictions with the Relational Data Manipulation Language (RDML) and
|  the RDML preprocessor.
|  
|  
|  
|  3.5.3.1.1  VAX C Host Variables - The following restrictions affect
|  how you may use VAX C host variables:
|  
|       1.  Host variables in VAX C of the form *host_variable that
|           appear directly after a host variable in an RSE are not


                                    3-20









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


|           detected correctly.  For instance, *year_ptr is incorrectly
|           interpreted as part of the host variable emp_id in the
|           following example:
|  
|                FOR D IN DEGREES WITH D.EMPLOYEE_ID = emp_id
|                    *year_ptr = D.YEAR_GIVEN;
|                END_FOR;
|  
|           The workaround for this restriction is to use braces around
|           the host language statements, or parentheses around the WITH
|           clause.  For example, either of the following RSEs will
|           preprocess correctly:
|  
|                FOR D IN DEGREES WITH D.EMPLOYEE_ID = emp_id
|                   {
|                   *year_ptr = D.YEAR_GIVEN;
|                   }
|                END_FOR;
|  
|                FOR D IN DEGREES WITH (D.EMPLOYEE_ID = emp_id)
|                   *year_ptr = D.YEAR_GIVEN;
|                END_FOR;
|  
|       2.  Although host variables with parentheses are permitted in
|           non-RDML statements, they cannot be used as host variables in
|           RDML statements.  For example the following is not permitted
|           syntax:
|  
|                FOR E IN EMPLOYEES 
|                   WITH E.LAST_NAME = (name)[offset].element
|                     .
|                     .
|                     .
|                END_FOR;
|  
|           However, the following is permitted:
|  
|                FOR E IN EMPLOYEES 
|                   WITH E.LAST_NAME = name[offset].element
|                     .
|                     .
|                     .
|                END_FOR;
|  







                                    3-21









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


|  3.5.3.1.2  VAX C String Continuation Character - The VAX C string
|  continuation character, (a backslash, \), in string constants followed
|  immediately by a new line is not recognized by RDML.  Do not use this
|  method of continuation with this version of RDML.  RDML generates an
|  error if it finds a string constant that does not begin and end on the
|  same line, within quotation marks.  For example, the following VAX C
|  lines cause a syntax error in Rdb/VMS V2.3:
|  
|  printf ("abcdefg\
|  hijklmnopqrstuvwxyz");
|  
|  
|  
|  
|  3.5.3.1.3  Handles in Statistical and Boolean Functions - RDML not
|  support transaction handles or request handles for statistical and
|  Boolean functions.  These functions are:
|  
|        o  AVERAGE
|  
|        o  COUNT
|  
|        o  MAX
|  
|        o  MIN
|  
|        o  TOTAL
|  
|        o  ANY
|  
|        o  UNIQUE
|  
|  
|  
|  
|  3.5.3.1.4  Path Name and the DATABASE Statement - RDML does not
|  extract the run-time filename from the CDD when you specify the
|  compile-time pathname option of the DATABASE statement only.  If you
|  choose to specify the compile-time path name, you must also supply the
|  run-time file name.  If you do not supply the run-time file name under
|  these conditions, RDML will use the CDD path name as the run-time file
|  name.  For instance, RDML will use mistakenly use 'CDD$TOP.PERSONNEL'
|  as the run-time database file name in the following example:
|  
|  DATABASE COMPILETIME PATHNAME 'CDD$TOP.PERSONNEL';
|  
|  However, RDML will correctly interpret the following DATABASE
|  statement:



                                    3-22









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


|  DATABASE COMPILETIME PATHNAME 'CDD$TOP.PERSONNEL'
|           RUNTIME FILENAME 'PERSONNEL';
|  
|  
|  
|  3.5.3.1.5  RDML Documentation Errors or Omissions - This section lists
|  RDML documentation errors:
|  
|       1.  Syntax diagram for request handles and transaction handles
|  
|           The use of the request handle and transaction handle together
|           is not accurately described by the syntax diagrams in the
|           RDML Reference Manual Rdb/VMS V2.2 documentation, (however,
|           the correct syntax diagrams appear in the RDML Pocket Guide
|           and the RDML online Help files).  For example, instead of the
|           syntax diagram appearing as:
|  
|           FOR  ----+--->------------------+----+-->-------------------------+
|                    +--->(request-handle)--+    +-->(transaction-handle) ----+
|                                                                             |
|           +--------------------------------<--------------------------------+
|           |
|           |
|           +--->  rse  --+->-----------+---+-->  statement  --+--> END_FOR
|                         +->on-error --+   +--<---------------+
|  
|  
|           It should appear as:
|  
|           FOR -----+----->--------------------------------------->--------+--+
|                    +-------------->  (REQUEST_HANDLE var) ----------------+  |
|                    +-------------->(TRANSACTION_HANDLE var)---------------+  |
|                    +-----> (REQUEST_HANDLE var,  TRANSACTION_HANDLE var)--+  |
|                                                                              |
|           +--------------------------------<---------------------------------+
|           |
|           |
|           +--->  rse  --+->-----------+---+-->  statement  --+--> END_FOR
|                         +->on-error --+   +--<---------------+
|  
|  
|       2.  Definition of the MATCHING conditional expression
|  
|           The RDML documentation for Rdb/VMS V2.2 containing the
|           definition of the MATCHING conditional expression did not
|           make clear that there are two ways to use it.  These two ways
|           are:




                                    3-23









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


|            o  Use the match symbols (the asterisk or the percent sign)
|               in combination with alphabetic characters to test for the
|               presence of a specified string inside a string
|               expression.  For example if you want to find all
|               employees with a last name that has "m" as the second
|               character, and "i" as the third, you might use the code
|               shown below:
|  
|               FOR E IN EMPLOYEES
|                  WITH E.LAST_NAME MATCHING "%mi**"
|                   .
|                   .
|                   .
|               END_FOR
|  
|            o  Supply an argument that will match the data stored in the
|               database exactly.  For example, using the PERSONNEL
|               database, if you want to find all the employees with the
|               last name Smith you need to append nine blanks to the
|               name.  This is because LAST_NAME is defined as TEXT 14 in
|               the PERSONNEL database.  If LAST_NAME were defined as
|               TEXT 5, you would not need to append blanks to the name.
|  
|               FOR E IN EMPLOYEES 
|                  WITH E.LAST_NAME MATCHING "Smith         "
|                   .
|                   .
|                   .
|               END_FOR;
|  
|  
|       3.  Host language multipath statements and RDML update statements
|  
|           RDML may return unpredictable results when host language
|           multipath statements (such as the C switch statement or the
|           PASCAL case statement) are embedded in RDML update statements
|           (STORE or MODIFY).  The problem occurs when a field is
|           referenced, but not used at run time.  This is because RDML
|           assumes that any field mentioned between MODIFY...END_MODIFY
|           or STORE ...  END_STORE is going to be updated.
|  
|           In the following examples, if the program falls through to
|           case 2 at run time, the FIRST_NAME field will be modified
|           even though FIRST_NAME is not referenced in case 2.  Upon
|           seeing the fields referenced in case 1, RDML sets up a buffer
|           for both FIRST_NAME and LAST_NAME to be sent to the database.
|           Because case 2 does not supply data for FIRST_NAME, RDML
|           sends to the database whatever happens to be in the buffer
|           for FIRST_NAME.


                                    3-24









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


|           The following C code will cause unpredictable results:
|  
|              FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = "00164"
|                MODIFY E USING
|                  switch (i){
|                   case '1':
|                      strcpy (E.LAST_NAME,"Smith         ");
|                      strcpy (E.FIRST_NAME,"Andrew    ");
|                      break;
|                   case '2':
|                  strcpy (E.LAST_NAME, "Jones         ");           
|                      break;
|                }
|                END_MODIFY;
|              END_FOR;
|  
|           Likewise, the following PASCAL code will cause unpredictable
|           results:
|  
|              FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = '00164'
|                MODIFY E USING
|                  case i of
|                   1: E.LAST_NAME = 'Smith';
|                      E.FIRST_NAME = 'Andrew';
|                   2: E.LAST_NAME = 'Jones';           
|                   end;
|                END_MODIFY;
|              END_FOR;
|  
|           When different fields are referenced in a multipath
|           statement, the RDML update statement should be embedded in
|           the host language multipath statement as shown in the
|           following examples.
|  

















                                    3-25









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


|           In C:
|  
|              FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = "00164" 
|                   switch(i) {
|                    case '1': 
|                        MODIFY E USING
|                         strcpy (E.LAST_NAME,"Smith         ");
|                         strcpy (E.FIRST_NAME,"Andrew    ");
|               END_MODIFY;
|               break;
|                 case '2':
|               MODIFY E USING
|                   strcpy (E.LAST_NAME, "Jones         ");
|               END_MODIFY;
|                      break;
|              }
|              END_FOR;
|  
|           In PASCAL:
|  
|              FOR E IN EMPLOYEES WITH E.EMPLOYEE_ID = '00164'
|                       case i of
|                         1: MODIFY E USING
|                              E.LAST_NAME = 'Smith';
|                              E.FIRST_NAME = 'Andrew';
|                            END_MODIFY;
|  
|                         2: MODIFY E USING
|                              E.LAST_NAME = 'Jones';
|                            END_MODIFY;
|                       end;
|                   END_FOR:



















                                    3-26









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


|       4.  C host variable syntax diagram
|  
|           The C host variable syntax diagrams in the RDML Reference
|           Manual for Rdb/VMS V2.2 are incomplete.  They does not
|           reflect the fact that the indirection operator (*) may be
|           used in host variables.  The correct syntax appears as
|           follows:
|  
|           host-variable (in C) =
|  
|           -+->---+- vax-name --+--+--------------------------->-----------+-+->
|            +-> * +             |  +--->  .   --->  field-identifier  -----+ |
|                                |  |                                       | |
|                                |  +--->  [  --->  expression  --->  ]  ---+ |
|                                |  |                                       | |
|                                |  |                                       | |
|                                |  +--->  "->"  ----> host-variable -------+ |
|                                +----------<-------------------------<-------+
|  
|  
|  
|  
|  
|  3.5.4  RDBPASCAL DATABASE Statement INCLUDES External Procedures
|  
|  The RDBPASCAL precompiler INCLUDES the file:
|  SYS$LIBRARY:RDBVMSPAS.PAS when the DATABASE statement is executed.
|  Three procedures in this system library are declared as external, they
|  are:  LIB$COPY_DXDX, LIB$CALLG, and LIB$STOP.  The external
|  declaration on these system services can cause a problem when you
|  attempt to use them in RDBPASCAL programs.  For example, in LIB$STOP
|  defined as follows in SYS$LIBRARY:RDBVMSPAS.PAS:
|  
|  [HIDDEN] PROCEDURE LIB$STOP:EXTERNAL;
|  
|  However, this declaration does not allow you to pass the condition
|  code of the signaled error to LIB$STOP.
|  
|  There are two suggested workarounds for this problem:
|  
|        o  Delete the procedure declarations from RDBVMSPAS.PAS and
|           declare the procedures within your source module, as desired.
|  
|        o  Use RDML PASCAL, which will not declare the procedures as
|           external.
|  





                                    3-27









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


|  3.5.4.1  G_FLOATING Problem in Precompiled FORTRAN Programs - The
|  RDBPRE precompiler runs the host language VAX FORTRAN compiler with
|  the /G_FLOAT qualifier.  Wrong data values will be returned by the
|  program when all of the following conditions are true:
|  
|        o  A variable is used in multiple modules.
|  
|        o  One module containing the variable is compiled with /G_FLOAT
|           (the result of being processed by the precompiler).
|  
|        o  Another module containing the variable is compiled with
|           /NOG_FLOAT (the default when a module is processed through
|           the FORTRAN compiler or other VAX language compilers).
|           /NOG_FLOAT results in a D_FLOAT variable.
|  
|        o  The two modules are linked together (no error results) and
|           pass data between each other.
|  
|  No error messages are ever seen; however, wrong data answers are
|  returned because one module passes a G_FLOAT representation of the
|  variable and the receiving module acts on the data as if it were
|  D_FLOATING.  To correct this problem, always compile FORTRAN host
|  language program modules with the /G_FLOAT qualifier.



   3.5.4.2  Header Information on Second Line of VAX BASIC Programs -
   When the RDBPRE precompiler creates a .BAS source file from a .RBA
   file, a header is printed on the second line of the .RBA file stating
   the .RBA file name, time stamp, and the precompiler version number.
   Forcing this text on the second line will cause VAX BASIC compilation
   errors if the first line of code was blank or continued.  The
   workaround is to add a single first line to the program (such as a
   comment character).



   3.5.4.3  Retrieving Segmented Strings in BASIC - The preprocessors
   require that you supply a static class string descriptor when passing
   segmented strings.  Currently, a preprocessor restriction does not
   allow a dynamic class descriptor.  VAX BASIC uses dynamic descriptors
   by default for all string variables; you must explicitly specify a
   static descriptor.  Using static descriptors will avoid a conflict
   that could result in a memory access violation.  And using static
   string descriptors means your VAX BASIC programs will retrieve
   segmented strings successfully.  Additionally, if you have programs in
   other languages that contain a call to LIB$GET_DD, you must use a
   static string descriptor.  The following program uses static strings
   to retrieve segments of a segmented string from the RESUMES relation


                                    3-28









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   of the PERSONNEL database.

   1       %title "Rdb SS access"
    !*
    !* displays a RESUME (SEGMENTED STRING)
    !*
       DECLARE STRING      emp_id,                         &
                           last_name,                      &
                           first_name,                     &
                           mi_name,                        &
                           resume_segment,                 &
                           ACL_TEXT

       DECLARE LONG        ACL_TEXT_LENGTH,                &
                           string_length

       DECLARE STR string_value
       RECORD STR
           STRING ST = 100
       END RECORD

       &RDB& invoke database filename "personnel"

   100     print 'getting an employee RESUME.'

       &RDB& START_TRANSACTION READ_ONLY

       string_value::st = space$ (100)
       &RDB& for r in resumes cross e in employees over employee_id
       &RDB&    GET                                      &
                   emp_id = E.EMPLOYEE_ID;                 &
                   last_name = E.LAST_NAME;                &
                   first_name = E.FIRST_NAME;              &
                   mi_name = E.MIDDLE_INITIAL;
       &RDB&    END_GET
           print
           print "Employee_id : ", emp_id
           print "Employee_name: ", first_name, mi_name, last_name
           print
       &RDB& for ss in r.resume
       &RDB&         GET
       &RDB&                     string_length  = SS.RDB$LENGTH;
       &RDB&                     string_value::st  = SS.RDB$VALUE;
       &RDB&         END_GET
           print string_length, string_value::st
           string_value::st = space$ (string_length)
       &RDB& end-for
       &RDB& end-for



                                    3-29









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


       &RDB&     COMMIT
       &RDB&     FINISH

       end



   3.5.4.4  Problems with Placement of VAX COBOL Line Terminator
   3.5.4.4  Problems with Placement of VAX COBOL Line Terminator - The
   placement of the VAX COBOL line terminator, a period ("."), within
   precompiled code may cause problems.  Several cases where this problem
   can occur are pointed out on page 5-8 of the V2.0 VAX Rdb/VMS Guide to
   Programming.  However, there are other cases.  For example:

   &RDB& INVOKE DATABASE AA = FILENAME "PERSONNEL".
   &RDB& INVOKE DATABASE BB = FILENAME "SHIPPING".

   The statements above will fail, but the following will succeed:

   &RDB& INVOKE DATABASE AA = FILENAME "PERSONNEL"
   &RDB& INVOKE DATABASE BB = FILENAME "SHIPPING".

   Or:

   &RDB& INVOKE DATABASE AA = FILENAME "PERSONNEL"
   &RDB& INVOKE DATABASE BB = FILENAME "SHIPPING"



   3.5.4.5  Concatenating Fields in Precompiled Programs - The
   concatenation operator (|) used in RDO is not recognized by RDBPRE
   precompiled program languages.  To concatenate fields in precompiled
   programs, first use the GET statement (in VAX PASCAL the WRITE,
   WRITELN, or assignment statements) to retrieve the individual fields
   into separate host language variables.  Then concatenate the host
   language variables in a host language statement using the host
   language concatenation operator.



   3.5.4.6  Using DATE Data Type in Precompiled FORTRAN and BASIC
            Programs - In precompiled VAX FORTRAN program you can now
   declare in your program any data type that can hold 64 bits as a
   variable to receive date fields.  In precompiled BASIC, however, you
   can no longer declare an array of 2 longwords to hold DATE data types.
   Instead declare a string of 8 bytes.  Existing programs will continue
   to run as expected until they are recompiled.  Then, redeclare your
   date fields as an 8-byte data structure rather than a 2-element
   longword array.



                                    3-30









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   The RDBPRE precompiler uses the Run-Time Library procedure LIB$MOVC3
   to move the value from the DATE data type to the host variable.  The
   precompiler declares LIB$MOVC3 as external for you; do not declare it
   again in your program, or you may receive a fatal compilation error.

   Here is an example of a FORTRAN program that accesses date fields as
   double precision, character, and CDD data types.

   IMPLICIT NONE

   &RDB& INVOKE DATABASE PATHNAME 'PERSONNEL'

   EXTERNAL SYS$ASCTIM
   CHARACTER*30 TIMBUF
   REAL*8 REAL_DATE
   CHARACTER*8 CHAR_DATE
   INTEGER TIMLEN

   DICTIONARY 'PERSONNEL.RDB$RELATIONS.JOB_HISTORY'
   RECORD /JOB_HISTORY/ JOB
   DATA TIMBUF /'                              '/     

   PRINT*, 'RETRIEVE A FEW DATE FIELDS'
   PRINT*, ' '
   &RDB& START_TRANSACTION READ_ONLY
   &RDB& FOR FIRST 5 J IN JOB_HISTORY WITH 
   &RDB&   J.JOB_END NOT MISSING
   &RDB&        GET JOB.JOB_END = J.JOB_END;
   &RDB&        REAL_DATE = J.JOB_END;
   &RDB&        CHAR_DATE = J.JOB_END; END_GET

   CALL SYS$ASCTIM(TIMLEN, TIMBUF, %REF(JOB.JOB_END),0)
   PRINT*,'JOB ENDING DATE (FROM CDD RECORD)  ',TIMBUF
   CALL SYS$ASCTIM(TIMLEN, TIMBUF, %REF(REAL_DATE), 0)
   PRINT*,'JOB ENDING DATE (REAL*8)  ',TIMBUF
   CALL SYS$ASCTIM(TIMLEN, TIMBUF, %REF(CHAR_DATE), 0)
   PRINT*,'JOB ENDING DATE (CHAR*8)  ',TIMBUF

   &RDB& END_FOR

   STOP
   END

   Here is the same program in VAX BASIC:

   10  !BEGIN

   &RDB& INVOKE DATABASE PATHNAME 'PERSONNEL'



                                    3-31









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


   EXTERNAL SUB SYS$ASCTIM
   DECLARE INTEGER TIMLEN
   DECLARE DOUBLE DATE
   DECLARE STRNG TIMBUF,STR

   RECORD STRNG
     STRING ST = 30
   END RECORD
   15 DECLARE JOB_HISTORY X
   20 %INCLUDE %FROM %CDD &
              "PERSONNEL.RDB$RELATIONS.JOB_HISTORY"
   30 TIMBUF::ST = '                              '

   &RDB& START_TRANSACTION READ_ONLY
   &RDB& FOR FIRST 5 J IN JOB_HISTORY WITH 
   &RDB&   J.JOB_END NOT MISSING
   &RDB& GET X::JOB_END = J.JOB_END;


   &RDB&     STR::ST = J.JOB_END;
   &RDB&     DATE = J.JOB_END; END_GET

   CALL SYS$ASCTIM (TIMLEN, TIMBUF::ST BY DESC, &
                   X::JOB_END BY REF, 0)
   PRINT "JOB ENDING DATE (FROM CDD RECORD)",TIMBUF::ST
   CALL SYS$ASCTIM (TIMLEN, TIMBUF::ST BY DESC, &
                   STR::ST BY REF, 0)
   PRINT "JOB ENDING DATE (STRING = 30)  ",TIMBUF::ST
   CALL SYS$ASCTIM (TIMLEN, TIMBUF::ST BY DESC, &
                   DATE BY REF, 0)
   PRINT "JOB ENDING DATE (DOUBLE)  ",TIMBUF::ST
   &RDB& END_FOR

   40  END



   3.5.4.7  Precompiling Without a Database - You cannot precompile a
   program that accesses a nonexistent database.  The database must be
   defined before the RDBPRE, RDBPASCAL, or RDML precompilers can
   validate relation and field definitions in the program that refers to
   the database.



   3.5.4.8  Using Database Fields as Array Subscripts - In Rdb/VMS
   precompiled BASIC, COBOL, and FORTRAN, you cannot use the name of a
   database field (a context variable and a field name) as a subscript of
   an array.


                                    3-32









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   However, in precompiled PASCAL programs, you can use the name of a
   database field as an array subscript in any place except within an
   RSE.  You cannot use a database field as an array subscript inside a
   record selection expression.  You can, however, retrieve the database
   value into a PASCAL variable and use this variable as an array
   subscript inside the record selection expression.



   3.5.4.9  Scaled Operands in VAX BASIC - If your precompiled VAX BASIC
   program requires numeric data that is stored in the Rdb/VMS database
   as scaled values, you can retrieve these scaled values into VAX BASIC
   host variables of any data type.

   For example, suppose the following variables are defined in an Rdb/VMS
   database:

   FIELD1          signed longword scale -2
   FIELD2          signed longword

   And suppose your BASIC program defines host variables, HOST_VAR_1 and
   HOST_VAR_2, as packed decimal.  In the following example Rdb/VMS
   converts scaled numeric data to packed decimal when it retrieves
   FIELD1 into HOST_VAR_1.

   &RDB&   FOR R IN RELATION_X
   &RDB&     GET
   &RDB&       HOST_VAR_1 = R.FIELD1;
   &RDB&       HOST_VAR_2 = R.FIELD2
   &RDB&     END_GET
   &RDB&   END_FOR

   You can then use these host variables to perform arithmetic operations
   in your BASIC program:

   HOST_VAR = HOST_VAR_1 + HOST_VAR_2

   However, you cannot perform arithmetic operations on scaled numeric
   data within an Rdb/VMS data manipulation statement because Rdb/VMS
   does not support the use of scaled operands in arithmetic expressions.
   For example, if HOST_VAR is defined in your BASIC program as packed
   decimal, the following operation will fail.

   &RDB&   FOR R IN RELATION_X
   &RDB&    GET 
   &RDB&        HOST_VAR = R.FIELD1 + R.FIELD2 
   &RDB&    END_GET
   &RDB&   END_FOR



                                    3-33









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


   Instead, to perform calculations on scaled numeric data you must first
   retrieve each database field value into a BASIC host variable of any
   numeric data type.  You can then use these host variables in BASIC
   arithmetic expressions to perform the necessary calculations.

                                    NOTE

           As an alternative, you can use SCALED QUADWORDs
           instead of PACKED DECIMAL.




   3.5.4.10  Comments Within DML Statements in VAX BASIC Programs - Use
   the comment character (!) to put comments within data manipulation
   language statements.  Because the VAX BASIC REM statement does not
   terminate the comment until the next line number, do not use REM
   within data manipulation statements.

   The precompiler converts all Rdb/VMS statements to comments in the
   BASIC program source file, replacing them with BASIC code.  Therefore,
   if an Rdb/VMS statement contains an exclamation point within a
   character constant, the precompiler doubles the exclamation point.
   The statement &RDB& STORE P IN PORT USING P.CITY = "MY_CITY!" becomes:

   !&RDB& STORE P IN PORT USING P.CITY = "MY_CITY!!" END_STORE

   If the precompiler did not double the exclamation point, the statement
   would look like the following in the .BAS file.

   !&RDB& STORE P IN PORT USING P.CITY = "MY_CITY!" END_STORE

   The BASIC compiler would interpret the following part of the text as a
   comment.

   !&RDB& STORE P IN PORT USING P.CITY = "MY_CITY! 

   The remainder of the example, then, would be interpreted as a BASIC
   statement, and an error would result:

   " END_STORE 



   3.5.4.11  ON ERROR Clause in Precompiled VAX COBOL Programs - The
   COBOL precompiler translates an Rdb/VMS FOR loop into an inline COBOL
   PERFORM loop.  You can use an ON ERROR clause that contains a GO TO
   statement to transfer program control out of this PERFORM loop when an
   error occurs in the execution of the FOR statement.  However, if you


                                    3-34









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   then use the /CHECK=PERFORM compiler qualifier, the system generates a
   run-time error and the program aborts.  Do not use the /CHECK
   qualifier if your program uses a GO TO statement to transfer control
   out of an Rdb/VMS FOR loop.



   3.5.4.12  Data Manipulation Statements in VAX FORTRAN Programs - You
   cannot use the FORTRAN/EXTEND_SOURCE switch in embedded data
   manipulation statements.  Text must be between columns 7 and 72,
   inclusive.  As in FORTRAN, the use of tabs will change the "apparent"
   column 72.  When you use the FORTRAN continuation character to
   continue an Rdb/VMS statement, do not mix tab and space characters in
   columns 1 to 7.



   3.5.4.13  START_STREAM Statement Within a FOR Loop - You may use the
   START_STREAM statement with a FOR loop.  However, you will receive the
   error RDB$_REQ_SYNC if you attempt to fetch a field defined in the FOR
   statement RSE more than once inside the stream.  The following example
   generates the error RDB$_REQ_SYNC because it attempts to retrieve the
   variable P.CITY (used in the FOR loop RSE) more than once inside the
   stream S.

           MOVE 'N' TO FOUND_END
   &RDB& FOR P IN PORT WITH P.CITY MATCHING '*D*'
   &RDB&   START_STREAM S USING E IN EXPORTER WITH 
   &RDB&      E.PORT_NUM = P.PORT_NUM

           PERFORM UNTIL FOUND_END IS EQUAL 'Y'
   &RDB& FETCH S 
   &RDB&     AT END 
                  DISPLAY " End of stream found "
                  MOVE 'Y' TO FOUND_END
   &RDB& END_FETCH
   *
   * Need conditional statement to branch around 
   * this code at stream end 
   *

           IF FOUND_END IS EQUAL TO 'N' THEN
   &RDB& GET
   &RDB&     CITY = P.CITY;
   &RDB&     NAM  = E.EXP_NAME; END_GET

           DISPLAY "City  ",CITY,"  Exporter  ",NAM
           END-IF
           END-PERFORM


                                    3-35









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


           MOVE 'N' TO FOUND_END
   &RDB& END_STREAM S
   &RDB& END_FOR

   Instead, retrieve the variable used in the FOR loop RSE outside the
   START_STREAM...END_STREAM block.  For example:

           MOVE 'N' TO FOUND_END
   &RDB& FOR P IN PORT WITH P.CITY MATCHING '*D*'
   &RDB&         GET
   &RDB&   CITY = P.CITY; END_GET

   &RDB&   START_STREAM S USING E IN EXPORTER WITH 
   &RDB&      E.PORT_NUM = P.PORT_NUM

           PERFORM UNTIL FOUND_END IS EQUAL 'Y'
   &RDB& FETCH S 
   &RDB&      AT END 
           DISPLAY " End of stream found "
           MOVE 'Y' TO FOUND_END
   &RDB& END_FETCH
   *
   * Need conditional statement to branch around 
   * this code at stream end 
   *
           IF FOUND_END IS EQUAL TO 'N' THEN
   &RDB& GET
   &RDB&      NAM  = E.EXP_NAME; END_GET

           DISPLAY "City  ",CITY,"  Exporter  ",NAM
           END-IF

           END-PERFORM

           MOVE 'N' TO FOUND_END
   &RDB& END_STREAM S
   &RDB& END_FOR



   3.5.4.14  Complex Variables in VAX PASCAL - RDBPASCAL currently limits
   the type of PASCAL expression that you can include in RSEs to
   expressions containing simple PASCAL variables and array or structure
   references.  You should assign complex expressions such as
   SUBSTR(STRING,1,24) to a temporary host variable; then use that
   variable inside your RSE in place of the complex expression.
   RDBPASCAL does not recognize complex host variable expressions such as
   elements of subscripted PASCAL record items.  If you use an element of
   a subscripted PASCAL record in an RSE, RDBPASCAL will not process the


                                    3-36









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   reference correctly and will generate incorrect PASCAL code.  Do not
   use the following PASCAL expressions in an RSE:

   x[1].y
   x.yZ

   However, you can use the following simple PASCAL expressions in an
   RSE:

   x
   x[1]
   x.y



   3.5.4.15  VAX PASCAL MIN and MAX Functions - Both Rdb/VMS and PASCAL
   V3.0 and later define MIN and MAX functions.  Therefore, to use the
   PASCAL MIN and MAX functions in Rdb/VMS precompiled programs, you must
   create two functions called PMIN and PMAX, which contain the PASCAL
   functions MIN and MAX.  Compile the PMIN and PMAX functions in a
   separate module using the PASCAL compiler only.  Then you can use PMIN
   and PMAX in precompiled PASCAL programs in place of the PASCAL MIN and
   MAX functions.  Remember to link the PMIN and PMAX object module with
   your precompiled program's object module.



   3.5.4.16  AVERAGE Statistical Expression in VAX PASCAL Programs - In
   RDBPASCAL, the values returned by the statistical expression AVERAGE
   are not in floating point format.  If the data type of the field being
   averaged is WORD or LONGWORD, the fractional part of the average value
   is lost.  To avoid this problem, retrieve the following separate
   values from the database:

         o  The TOTAL value of the field being averaged

         o  The COUNT of the records with the desired field NOT MISSING

   Then use a PASCAL expression to divide the TOTAL by the COUNT to
   obtain the average.

   A second, less desirable solution, but one which has better
   performance characteristics, is to create a copy of the database in
   which the field being averaged has a data type of REAL.  Then
   precompile your program against this copy of the database, so that
   RDBPASCAL generates the correct binary language representation (BLR)
   and floating point variable types.  Finally, run the program against
   whatever database you choose to obtain a floating point average.



                                    3-37









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


   The following is an example of the compile-time database definitions.

   DEFINE DATABASE 'DB'.
   !
   DEFINE FIELD DBFLD
           DESCRIPTION IS /* real field for compile */
           DATATYPE IS REAL.
   !
   DEFINE RELATION DBREL.
           DBFLD.
           END DBREL RELATION.

   An example of the run-time database definitions follow.

   DEFINE DATABASE 'DB'.
   !
   DEFINE FIELD DBFLD
           DESCRIPTION IS /* signed word field */
           DATATYPE IS SIGNED WORD.
   !
   DEFINE RELATION .
           DBFLD.
           END DBREL RELATION.



   3.5.4.17  DATE Data Type in VAX PASCAL - RDBPASCAL does not generate
   diagnostics if you attempt to:

         o  Perform arithmetic operations on DATE data types.

         o  Use the RDB$MISSING() function with a field that has a DATE
            data types.  Instead, RDBPASCAL generates incorrect code.
            Thus, you cannot use the RDB$MISSING operator with a DATE
            data type field in RDBPASCAL.




   3.5.4.18  Preprocessor File Names for Multiple Module Programs - If
   your program uses an object library, the file name of each module in
   the library must be unique in the first 27 characters.  Because most
   object file names are derived from the source file name, make sure
   that the conventions for naming your source files also observe this
   rule.






                                    3-38









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


   3.5.5  Callable RDO Programs

   The following sections describe known problems, restrictions, and
   workarounds pertaining to programs using RDB$INTERPRET.



   3.5.5.1  RDB$INTERPRET and Precompiled Modules - You can call
   RDB$INTERPRET in a precompiled Rdb/VMS program.  You must invoke the
   database in both the precompiled and the interpreted sections of the
   program.  When your program accesses more than one database, use
   database handles in all data manipulation statements whether they are
   precompiled or interpreted.  You do not need to use database handles
   if the program accesses only one database.  When the interpreted
   portion of the program invokes the database, Rdb/VMS uses the default
   database, which is the database already invoked by the precompiled
   portion of the program.

   If you call RDB$INTERPRET for data definition, do not use database
   handles or transaction handles in your data definition statements.
   Currently there are neither database handles nor transaction handles
   on data definition statements.  Do not issue precompiled data
   manipulation statements that rely on metadata defined in the
   interpreted sections of the same program.  The precompiler will not be
   able to reference metadata that has not yet been defined.



   3.5.5.2  INVOKE DATABASE EXTERNAL Not Supported - INVOKE DATABASE
   EXTERNAL and INVOKE DATABASE GLOBAL are not supported in
   RDB$INTERPRET.  Use these forms of the INVOKE statement in precompiled
   languages when you declare database handles.



   3.5.6  Error Messages

   The following error messages may indicate an incorrect database,
   request, segmented-string, or transaction handle:

   NOARGACC_READ database system can't read argument !UL

   NOARGACC_WRITE database system can't write argument !UL

   If you receive one of the former error messages, the error may be one
   of the following RDB facility errors:

   BAD_DB_HANDLE
   BAD_REQ_HANDLE


                                    3-39









   KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
   Programming


   BAD_SEGSTR_HANDLE
   BAD_TRANS_HANDLE



   3.5.7  Logical Names for Detached Processes Using Rdb/VMS

   If you create an Rdb/VMS application that runs as a detached process,
   a problem may occur because the process permanent logical names (in
   particular SYS$LOGIN and SYS$SCRATCH) are not defined for detached
   processes.  SYS$LOGIN is used typically for RUJ files and bugcheck
   dumps, while SYS$SCRATCH is used for the temporary files created by
   VMS Sort.

   These names can be defined at the system or group level using the DCL
   DEFINE command.  Or, your program can define them.



   3.5.8  DSRI Restrictions

   This section describes restrictions in the DIGITAL Standard Relational
   Interface (DSRI) as they relate to Rdb/VMS.
|  
|  
|  
|  3.5.8.1  Do Not Enable the VMS System Service SYS$SETSFM - DIGITAL
|  recommends that high-level language programs not enable system service
|  failure mode (SYS$SETSFM), except perhaps in debugging situations.  If
|  the SYS$SETSFM System Service is called with the enable flag set, a
|  software exception is generated when a system service returns an error
|  or severe error condition value.  If no condition handler is specified
|  by the user, a default system handler is used.  This condition handler
|  causes the image to exit and the condition handler will contain the
|  code SS$_SSFAIL in the condition name argument of the signal array.
|  
|  If you must enable SYS$SETSFM for your particular application, make
|  certain that you disable it before executing Rdb/VMS Data Definition
|  statements or Data Manipulation statements.
|  
|  For more information see the VAX/VMS System Services Reference Manual.



   3.5.8.2  Unsupported Calls - The current version of Rdb/VMS does not
   support the following elements of DSRI:

         o  RDB$PREPARE_TRANSACTION



                                    3-40









                            KNOWN PROBLEMS, RESTRICTIONS, AND WORKAROUNDS
                                                              Programming


            Rdb/VMS accepts the call, but will always return a success
            condition, even when this is not the case.

         o  RDB$RECONNECT

            Rdb/VMS accepts the call, but will always return
            RDB$_NO_RECON (reconnect failed), even when this is not the
            case.
|  
|        o  TPB$_CONCURRENCY
|  
|           Rdb/VMS does not support the concurrency option.  If
|           TPB$_CONCURRENCY is specified, it is converted to
|           TPB$_CONSISTENCY.
|  
|        o  Multiple transactions against a single database attachment
|  
|           In Rdb/VMS, the maximum number of transactions that can be
|           started against a single database attachment is one.
|  
|        o  Instantiation
|  
|           Rdb/VMS validates instantiation parameters.  However, it does
|           not support multiple instantiations of a request.  An attempt
|           to start a second instantiation of a request results in an
|           RDB_IMP_EXC exception.  Use of invalid instantiation
|           parameters results in an RDB_REQ_SYNC exception.
|  
   Information about the DSRI calls are documented in the DIGITAL
   Standard Relational Interface (DSRI) Handbook.



   3.5.8.3  Passing Invalid BLR with RDB$COMPILE_REQUEST - An access
   violation may occur if the wrong binary language representation (BLR)
   length is passed in the RDB$COMPILE_REQUEST Relational Call Interface
   (RCI) routine to a DSRI-compliant database system.

   If the "request_length" parameter's value is shorter than the actual
   size of the BLR string being passed, the access violation may result.
   To determine the cause of the access violation, set the logical name
   RDMS$DEBUG_FLAGS to "B", run the program again, and examine the
   warning message about "BLR$K_EOC." Then ensure that the
   "request-length" parameter of RDB$COMPILE_REQUEST is large enough to
   include the BLR$K_EOC.






                                    3-41
